What I expected from HTML5 and CSS3

    I have been doing web development for a long time, and I also remember IE3 and NN4.xx. Much has changed since then, much water has flowed. An understanding of all technologies came not at the level of "HTML is a text file that contains some words in brackets", but an understanding of the logic of building the markup language itself, its abstractions.

    The beginning of the development of HTML5 and CSS3 specifications no longer caused me puppy delight and wild joy, but was perceived as a completely evolutionary event. I occasionally looked into draft drafts, noting for myself the main directions of development. But the more specifications come closer to 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 did the innovation go? Why is w3c creating a standard that, by some standards, is already outdated?

    Let's figure it out.


    HTML5


    One of the most obscure to me tags are del and ins . They went through the entire structure of the language with a dirty hack, while having very dubious benefits. Attempts to transfer the logic of office documents to a web page will end in complete fiasco. Why? Yes, very easy! If you need to get a history of document changes, you can do this with external programs without transferring this functionality into the language. Less than one hundredth of a percent of users need a revision history, all the rest are calmly content with the current current version of the data at the time of information search. Parsing the code, taking into account these two “wonderful” tags, will be a complete negative, because the harmony of the language and its consistency, its predictability are violated.

    The second trick is an attempt to put things into the HTML that could not be added there in any case. These are contenteditable , draggable, and other interactive attributes . This should be rendered in CSS, DOM, anywhere, but not in HTML. These are interactive, not markup. The interactivity has to be manageable, and there is great JS and great CSS to manage it. Writing these attributes directly in HTML - very much smacks of HTML sample version 3.2.

    The third joke is pathetic attempts 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 so. Let's step aside from this topic and discuss why HTML is needed. And he is needed in order to mark up some information. At this point in time, markup includes not only content, but also design delights. So, we have flies separately (structures that are needed for decoration purposes), and cutlets separately (directly the content itself). HTML is a great fit for content, but there are big problems with designer refinements. Yes, and the logical structure of the page is also a problem. One has a menu, sidebar and content on the site, and the second has a header with the main menu, a secondary menu, two sidebars left and right, an advertising box, a list of products and more. How to make them friends? Yes Easy! You just need to let your tags come up! XML for page design, HTML - for content design. Why not use XML right away? With it there will be more difficulties for search engines. On the market there is a successful solution to search problems with such a structure of documents - microformats. By creating, for example, the behavior attribute, which will describe the behavior of an element, you can safely tell search engines where and what you have organized. On the market there is a successful solution to search problems with such a structure of documents - microformats. By creating, for example, the behavior attribute, which will describe the behavior of an element, you can safely tell search engines where and what you have organized. On the market there is a successful solution to search problems with such a structure of documents - microformats. By creating, for example, the behavior attribute, which will describe the behavior of an element, you can safely tell search engines where and what you have organized.

    All kinds of input forms were created. Forgot to just figure out how to style all this wealth. I understand that the uniformity of the interface is an important thing, but styling can be both a positive and a negative factor in the development of web interfaces. The market requires this, so you need to do it.

    So we went smoothly to the CSS3 theme

    CSS3


    Continuing the theme of web forms. The web interface market expects a controlled styling 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? But nothing.

    The template layouts first inspired me, 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 browser window, must line up one after another, and occupy either one line, or two, three, four lines. Regular floats. That's all, collapse, because the template does not describe the behavior of the block and moving it if it does not fit into a certain space. The position of the block in the template is clearly fixed, it will be extremely difficult to do adaptive layout. And this requires the market, and now it is done with the help of crutches. In addition, it is not entirely clear how, when changing the DOM tree, the block that has a clear position in the template on the page will behave. But it doesn’t bother anyone, we make magazine layouts 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 reference point at the given time is one - the upper left corner. The calculation of the position of the same background is 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 create a multi-language design without crutches. And the solution to the problem is all under the nose - you just need to change the starting point, and the background position for the inhabitants of Saudi Arabia would miraculously remain unchanged, for example 10px 10px, and would be in the upper right corner, exactly at this offset. Developing an idea with a reference point, you can find more controlled control of the position of absolute elements, control of the transformation of objects and much more. But I did not find this in the specification.

    You can list the problems for a long time. Do not think that my task is to denigrate w3c, very smart people work there. Just during the creation of the new specification, part of the original goals ceased to be relevant. The market is developing very fast, and w3c requires more interactivity with developers. My main goal is to make people think about what they are doing and how they think.

    UPD: Many thanks to everyone for the positive and negative karma!
    UPD2: Changed paragraph about display templates

    Also popular now: