What I expected from HTML5 and CSS3
I have been working on web development for a long time, and I still remember IE3 and NN4.xx. Much has changed since then, much water has flowed. The understanding of all technologies came not at the level “HTML is a text file in which some words in parentheses come across”, but an understanding of the logic of building the markup language itself, its abstractions.
The beginning of the development of the specifications of HTML5 and CSS3 did not cause me puppy delight and stormy joy, but was perceived as a completely evolutionary event. I looked into working drafts occasionally, noting for myself the main directions of development. But the more the specifications approach the final, the worse it gets. This is not the direction of development that the market requires!
A reasonable question arises, where did all those people who developed standards 10 years ago go? Where are the innovations? Why does w3c create a standard that, by some standards, is already outdated?
')
Let's see.
One of the most incomprehensible tags to me are del and ins . They went through the entire structure of the language with a dirty hack, while having a very dubious advantage. Attempts to transfer the logic of office documents to a web page will end in fiasco. Why? Yes, very simple! If you need to get a history of changes to a document, you can do this with external programs, without transferring this functionality into the language. The history of edits is needed by less than one hundredth of a percent of users; all others are quietly content with the current actual version of the data at the time of searching for information. Parsing the code with these two "wonderful" tags will be a continuous negative, because the harmony and logic of the language, its predictability are violated.
The second joke is an attempt to stick things into HTML that couldn’t be added there in any way. These attributes are contenteditable , draggable, and other interactive features. This should be rendered in CSS, DOM, anywhere, just not in HTML. These are interactive, not markup. The interactive should be manageable, and for management there is a wonderful JS and great CSS. Write these attributes directly in HTML - smacks HTML sample version 3.2 very much.
The third joke is a pitiful attempt to structure the document by introducing additional structural elements. It's just some kind of circus. For these words, they will throw slippers at me, but I hope a number of people will understand why I say that. Let's move away from this topic to the side and speculate about why we need HTML. And you need it in order to make some information markup. At this point in time, the markup includes not only content, but also designer delights. So, we have flies separately (structures that are needed for design purposes), and cutlets separately (the content itself). For HTML content is suitable with a bang, but with design delights a big problem. Yes, and with the logical structures of the page are also problems. One has a menu on the site, a sidebar and content, and the second has a header with a main menu, a secondary menu, two sidebars on the left and right, an advertising box, a list of products and so on. How to make friends? Yes Easy! You just need to let them invent their tags! XML for page design, HTML for content design. Why not immediately use XML? With him there will be more difficulties for search engines. There is a successful solution to the problems of search in the market with such a structure of documents - microformats. By creating, for example, the behavior attribute, which will contain a description of the element's behavior, you can safely tell search engines where and what you have organized.
We created various types of input forms. Forgotten just think of how to stylize all the wealth. I understand that the monotony of the interface is an important thing, but stylization can be both a positive and a negative factor in the development of web interfaces. The market requires it, so you need to do it.
Here we come smoothly to the topic of CSS3
We continue the topic of web forms. The web interface market expects controlled stylization of input fields. In practice, this means that I want to make any input field from any element. I want to make a checkbox with my own design, I want to make a selectbox with my own design, create each option from my own XML structure, and so on. What do we see in the working version of the specification? And nothing.
Template Layout inspired me at first, then, after modeling real situations, I realized that this would not work at all. If the content is static, then this approach will work. But as soon as the dynamics appear ...
Let's take a completely normal situation: we have four blocks, which, depending on the width of the content or the browser window, should line up one after another, and take either one line, or two, three, four lines. Common floats. Everything, collapse, because the template does not describe the behavior of the block and its movement in case it does not fit into a certain space. The position of the block in the template is clearly fixed, adaptive layout will be extremely difficult to do. And this requires the market, and this is now done with the help of crutches. In addition, it is not entirely clear how when changing a DOM tree, a block that has a clear position in the template on the page will behave. But nobody cares, we make a magazine layout from web pages. I wrote about this to D. Baron, but the effect is zero.
Let's go back to another very important thing called the reference point. The starting point at this point in time is one - the left upper corner. Calculation of the position of the same background is exactly from this place. But in the world there are not only those who read from left to right, but also those who read from right to left, from top to bottom, and so on. Now try to make a multilanguage design without crutches. And the solution to the problem for all under the nose - you just need to change the point of reference, and the background position for Saudis would miraculously remain unchanged, for example 10px 10px, and would be in the upper right corner, exactly by this offset. Developing an idea with a reference point, one can find a more manageable control of the position of absolute elements, control of the transformation of objects, and many useful things. But I did not find this in the specification.
Transfer inconsistencies can be long. Do not think that my task is to denigrate the work of w3c, very smart people work there. Just during the creation of a new specification, part of the original goals has ceased to be relevant. The market is developing at a very fast pace, and w3c needs more interaction with the developers. My main goal is to make people think about what they do and how they think.
UPD: Thank you so much for all the positive and negative karma!
UPD2: Changed the paragraph about display templates
The beginning of the development of the specifications of HTML5 and CSS3 did not cause me puppy delight and stormy joy, but was perceived as a completely evolutionary event. I looked into working drafts occasionally, noting for myself the main directions of development. But the more the specifications approach the final, the worse it gets. This is not the direction of development that the market requires!
A reasonable question arises, where did all those people who developed standards 10 years ago go? Where are the innovations? Why does w3c create a standard that, by some standards, is already outdated?
')
Let's see.
HTML5
One of the most incomprehensible tags to me are del and ins . They went through the entire structure of the language with a dirty hack, while having a very dubious advantage. Attempts to transfer the logic of office documents to a web page will end in fiasco. Why? Yes, very simple! If you need to get a history of changes to a document, you can do this with external programs, without transferring this functionality into the language. The history of edits is needed by less than one hundredth of a percent of users; all others are quietly content with the current actual version of the data at the time of searching for information. Parsing the code with these two "wonderful" tags will be a continuous negative, because the harmony and logic of the language, its predictability are violated.
The second joke is an attempt to stick things into HTML that couldn’t be added there in any way. These attributes are contenteditable , draggable, and other interactive features. This should be rendered in CSS, DOM, anywhere, just not in HTML. These are interactive, not markup. The interactive should be manageable, and for management there is a wonderful JS and great CSS. Write these attributes directly in HTML - smacks HTML sample version 3.2 very much.
The third joke is a pitiful attempt to structure the document by introducing additional structural elements. It's just some kind of circus. For these words, they will throw slippers at me, but I hope a number of people will understand why I say that. Let's move away from this topic to the side and speculate about why we need HTML. And you need it in order to make some information markup. At this point in time, the markup includes not only content, but also designer delights. So, we have flies separately (structures that are needed for design purposes), and cutlets separately (the content itself). For HTML content is suitable with a bang, but with design delights a big problem. Yes, and with the logical structures of the page are also problems. One has a menu on the site, a sidebar and content, and the second has a header with a main menu, a secondary menu, two sidebars on the left and right, an advertising box, a list of products and so on. How to make friends? Yes Easy! You just need to let them invent their tags! XML for page design, HTML for content design. Why not immediately use XML? With him there will be more difficulties for search engines. There is a successful solution to the problems of search in the market with such a structure of documents - microformats. By creating, for example, the behavior attribute, which will contain a description of the element's behavior, you can safely tell search engines where and what you have organized.
We created various types of input forms. Forgotten just think of how to stylize all the wealth. I understand that the monotony of the interface is an important thing, but stylization can be both a positive and a negative factor in the development of web interfaces. The market requires it, so you need to do it.
Here we come smoothly to the topic of CSS3
CSS3
We continue the topic of web forms. The web interface market expects controlled stylization of input fields. In practice, this means that I want to make any input field from any element. I want to make a checkbox with my own design, I want to make a selectbox with my own design, create each option from my own XML structure, and so on. What do we see in the working version of the specification? And nothing.
Template Layout inspired me at first, then, after modeling real situations, I realized that this would not work at all. If the content is static, then this approach will work. But as soon as the dynamics appear ...
Let's take a completely normal situation: we have four blocks, which, depending on the width of the content or the browser window, should line up one after another, and take either one line, or two, three, four lines. Common floats. Everything, collapse, because the template does not describe the behavior of the block and its movement in case it does not fit into a certain space. The position of the block in the template is clearly fixed, adaptive layout will be extremely difficult to do. And this requires the market, and this is now done with the help of crutches. In addition, it is not entirely clear how when changing a DOM tree, a block that has a clear position in the template on the page will behave. But nobody cares, we make a magazine layout from web pages. I wrote about this to D. Baron, but the effect is zero.
Let's go back to another very important thing called the reference point. The starting point at this point in time is one - the left upper corner. Calculation of the position of the same background is exactly from this place. But in the world there are not only those who read from left to right, but also those who read from right to left, from top to bottom, and so on. Now try to make a multilanguage design without crutches. And the solution to the problem for all under the nose - you just need to change the point of reference, and the background position for Saudis would miraculously remain unchanged, for example 10px 10px, and would be in the upper right corner, exactly by this offset. Developing an idea with a reference point, one can find a more manageable control of the position of absolute elements, control of the transformation of objects, and many useful things. But I did not find this in the specification.
Transfer inconsistencies can be long. Do not think that my task is to denigrate the work of w3c, very smart people work there. Just during the creation of a new specification, part of the original goals has ceased to be relevant. The market is developing at a very fast pace, and w3c needs more interaction with the developers. My main goal is to make people think about what they do and how they think.
UPD: Thank you so much for all the positive and negative karma!
UPD2: Changed the paragraph about display templates
Source: https://habr.com/ru/post/101746/
All Articles