HTML5 Design principle

HTML5 is a huge leap in web standards, why should it contain those things, and what are the design principles behind it?

"JavaScript DOM programming Art" and "HTML5 for Web Designer" author Jeremy Keith reviewed the evolution of HTML, shared HTML5 design principles, and interacted with the attendees.

First, Jeremy reviews the history of HTML, from HTML 2.0 to XHTML 2.0, where he cites the Postel rule (Robustness principle):

Be strict with what you send, and be tolerant of what you receive. It is pointed out that XHTML 2.0 is not suitable for the web because of its strict syntax parsing.

Jeremy that all the projects should have design principles, HTML5 is the same, the Internet has published the principles of HTML design, he emphasized the compatibility, practicality and interoperability.

1. Avoid unnecessary complexity

Jeremy The example of DOCTYPE, which means that the DOCTYPE in HTML 4.01 and XHTML are too lengthy to remember these things, but simply <! in HTML5 DOCTYPE html> will be all right. DOCTYPE is for validators, not browsers, the browser only pays attention to this tag when doing DOCTYPE switching, so it doesn't have to be too complicated to write. He then mentions how to specify a character set, and in HTML5 only <meta charset= "Utf-8" >.

The specification may be very complex, but the implementation of the browser may be simple, and the specification will sometimes indulge the browser's implementation.

2. Support Existing content

The biggest problem with XHTML 2.0 is that it doesn't support existing content, which violates the Postel rule. In reality, developers can write a variety of styles of HTML, when the browser encounters the code, the structure inside the building should be the same, the effect should be the same.

3. Solve Practical problems

The norm should solve the actual problems in reality, but should not consider the complicated theoretical problems. For example, since there is a need to nest multiple paragraph labels in <a>, let the spec support it.

4, how to use the user, on how to design norms

When a practice has been widely accepted, it is necessary to consider absorbing it instead of banning it or engaging in a new practice.

For example, the NAV, section, article, and aside tags are added to HTML5, which introduce a new document model, a document in a document. In the section, you can also nest H1 to H6 tags, so there is an infinite heading hierarchy, as Tim Berners Lee envisioned earlier.

5. Gracefully downgrade

Jeremy The example of input here, the Type property of the input tag in HTML5 adds many types, and when the browser does not support these types, it is treated as text by default. This is an elegant downgrade.

In addition, when it comes to the battle between HTML5 and Flash, he thinks that in many cases, this is the problem of <video> and <object>, and there is absolutely no need to choose between them. You can use <video> first, demote to <object> when the browser is not supported, and vice versa. If the browser does not support both, and then downgrade to <a>, provide a link.

6, the priority level of support

When considering priorities, you should follow this order:

Users > Developers writing HTML > Browser vendors > Spec makers > Theory

Users and developers are far more important than norms and theories.

In the final question-and-answer session, it was mentioned that HTML5 's grammar was too flexible, would create some abuse, Jeremy agreed, and recommended the use of JavaScript-lint-like tools to help write better code.

In addition, some people worry that the <video> appearance of the customization is not strong, the control is not beautiful, may repeat the mistakes of <select>. Jeremy on the spot demonstrates a custom style of <video> through CSS, and says that if you don't like the controls provided by the browser, you can implement your own controls completely.

Http://developer.51cto.com/art/201104/256672.htm

Robustness Law, Bostal law, "to be conservative when sending, open to accept", this is a very high demand for developers, first of all to let oneself strictly according to the norms to do, and secondly to tolerate others as far as possible the standards of things, this week especially important, we can not strictly others according to standards to do, But try to get the best deal out of their input, so you need to consider all kinds of anomalies and make a choice of exceptions. XHTML2 is too strict and incompatible with the previous HTML, so it is not used at the end.

HTML5 development process is also very twists and turns, began to confirm XHTML2 is the direction of the future against the continued development of HTML, so some browser manufacturers set up a Web hypertext applications technology working Group (web Hypertext Application Working Group, WHATWG) Add new things on the HTML basis and do the browser, the efficiency is very high, soon has the effect, and the XHTML2 of the world-class has no substantial progress. In 2006, the consortium agreed to develop HTML5 work together with WHATWG. The concept of two working groups is completely different, the former is a dictatorship work mechanism, and the world wide is a democratic work mechanism, everyone has voting power, but in practice the former working mechanism is better, it is mainly attributed to Ian Hickson, thanks to Ian Hickson, when he listened to the views of all parties, Can always do without the slightest personal feelings. The two working groups were ultimately able to work together, mainly because of HTML5 's design ideas, since they initially identified the principles that the design HTML5 insisted on.

XHTML 2 still uses the XML error-handling model, and you have to ensure that documents are sent as XML document types, which is self-evident: no one wants to do this. Second, XHTML 2 is intentionally no longer backwards compatible with the various versions of existing HTML. They have even discussed the abolition of the IMG element, which is a bit of a crazy taste for people who are doing web development every day. But we know that the reason they do this is theoretically good enough-it might be better to use the object element.

So, no matter how perfect a format XHTML 2 is in theory, it never had a chance to put it into practice. And it's hard to put it into practice because developers like you and me will never support it, and it's not backwards compatible. Similarly, browser vendors do not, and browser vendors must ensure backwards compatibility.

Why is XHTML 1.1 not so widely used as XML, and why XHTML 2 has never been implemented? Because it violates a design principle, this design principle is the famous Bostalfa (Postel's Law). As we all know:

be conservative when you send it, and open when you receive it.

Yes, it's open when you receive it, and that's the basis for the web to build. The person who develops the browser must be open-minded and receive everything that is sent to the browser because they have been receiving things that are not standard enough in the past, right? Many documents on the Web are not standardized, but that is the driving force of web development. From a certain point of view, the Web is a path of chaotic development, although chaotic, but very beautiful and attractive. On the web, documents with irregular formats can be found everywhere, but what then? If everyone can write accurate XML, all the documents are in the right format, that's fine. But that's not true. Reality is the law of Bostal.

As a professional, when sending a document, we try to be as conservative as possible and use best practices to ensure that the document is well-formed. But from the browser's point of view, they have to accept any document in an open posture.

One might say that XML has an error-handling model, both XHTML 1.1 and XHTML 2 use the model, but that error-handling model is too harsh. It is absolutely not in line with the law of opening the reception, and encountering a mistake to stop parsing how can it be called open? We can only say that it is antagonistic to the law of robustness (i.e. Bostalfa).

At a seminar in 2004, the representative of Ian Hickson, Ian Hickson, presented a proposal to expand and improve the HTML. He suggested that the new task force could be parallel to XHTML 2, but work on existing HTML, with the goal of extending HTML. The result of the poll was--"objection", because HTML is dead, and XHTML 2 is the future direction. Then, browser makers such as Opera, Apple, and others said, "Well, don't count on them, we can do it as we are, we're out of the web." "They set up the Web Hypertext Applications Technology Working Group (web Hypertext Application Working Group, WHATWG)--happen, they call themselves workgroups, not special groups (Task Force), This is to HTML5 the fate of the future to bury the foreshadowing.

WHATWG decided to get out of the world, work on the basis of HTML and add something new to it. The members of this working group have browser vendors, so they can not only say add-on, but also can be achieved. As a result, we constantly put forward some good ideas, and one by one to do the browser.

WHATWG efficiency is very high, soon the initial results. In the meantime, there has been little real progress on the XHTML 2. In particular, if from the point of view of implementation, it is not too far to describe in situ.

As a result, something interesting happened. That was in 2006, Tim Berners-Lee wrote a blog that said, "Do you know?" We were wrong. We were wrong in an attempt to let the Web into the XML era overnight, our idea is too unrealistic, yes, maybe we should re-assemble the HTML workgroup. "Good-to-speak, and then the story of the plot is indeed this development." The HTML5 group was formed in 2007. The first question facing the Working Group is no doubt, "are we starting from scratch, or are we working on the basis of the results of the working Group that was set up in 2004 called WHATWG?" "The answer is obvious, and they certainly want to start working on the basis of what has been achieved." They then voted again and agreed to "continue working on the basis of WHATWG work". All right, now they're going to fight with WHATWG.

The second question is how to straighten out the relationship between the two working groups. Who should be the editor of this working group? is not also let WHATWG's editor, namely now Google's Ian Hickson concurrently? So they voted again, in favor of "let Ian Hickson as the editor of the HTML5 Standard, and also the editor of WHATWG, which will help the new working group to carry out the work." ”

This is the result of their vote, the situation we see today: A format, two versions. WHATWG's website has this specification, and the Web site also has a copy.

If you're not in the know, you're likely to get the question: "Which version is the real spec?" "Of course, the contents of these two editions are the same ... Basically the same. In fact, these two versions will go their separate ways in the future. Now there are signs of parting. I mean, the world is going to end up with a specific specification that will become a working draft, fixed at some point in history.

And WHATWG, they are constantly iterating. Even the HTML5 we are talking about now cannot fully cover the work that WHATWG is doing. The most accurate understanding is that they are developing a simple HTML or Web technology, because that is the core goal of their work. However, there are two such working groups at the same time, the two working groups develop a basic same norm at the same time, which is easily misleading in any case. Misunderstanding can cause trouble.

In fact, the two working groups have their own processes behind each other, because their ideas are completely different. In WHATWG, it can be said to be a dictatorship of the working mechanism. I just said, Ian Hickson is an editor. He will listen to the views of all parties, and after all members have expressed their opinions and fully stated their views, he approves the opinions that he thinks are correct.

On the contrary, it can be said that it is a democratic working mechanism. All members can express their views, and everyone has the right to vote. The key to this process is to vote. On the face of it, the working mechanism of WHATWG is not acceptable to people. It's not just a bad reception, it's a throwback to history. I believe anyone will think that "no project can be done in this way!" ”

The working mechanism of the system sounds very comfortable to us. At least it embodies the equality of all. But in practice, the working mechanism of WHATWG is very, very good. I think the reason for this is mainly due to Ian Hickson. He is indeed a very competent editor. When he listens to the views of all parties, he can always do without personal feelings.

In principle, the work mechanism is fair, but in fact it is very easy to jam in certain processes or links, resulting in work stagnation, a matter to reach a resolution often takes a long time. So what kind of working mechanism is best? I think the best working mechanism is to combine the two. And the fact is that the two norm-setting bodies work together to develop a common norm, which, I think, is very beneficial to the two working mechanisms that complement each other.

The main reason why two working groups can work with each other is HTML5 design ideas. Because they have determined from the beginning that the design of the HTML5 to adhere to the principles. As a result, we saw not only a specification, the document published on the Web site, that is, the HTML5 language specification, but also on the Web site saw another document, that is, the principle of HTML design. And one of the editors of this document came to the scene of our conference today, and she was Annie Chi Tess (Anne Van Kesteren). If you have any questions about this document, you can ask Annie.

This document is very good, really excellent. This document, can be said to witness the WHATWG together with the development of the process of collusion. Don't you think they're like a pair of joy enemy? So how do they all have their heart? This document faithfully records what they have done together and what they collectively espouse.

The next thing I want to talk about is this document. Because, since they can agree on this document, I believe that HTML5 is bound to be a great norm, and they have recognized that this is their common platform of action. To do this, you will see concepts such as compatibility, practicality, interoperability, and so on. Even if there is a lot of disagreement between the WHATWG and the big one--and indeed quite a lot--at least they have the consensus documented in the document. This is the key point. Because they have a consensus, this document is based on a consensus description of design principles.

https://kb.cnblogs.com/page/79308/

HTML5 Design principle