May 03, 2021 HTML
1. Problems that can be caused by nesting errors
2. Strict nesting constraints, semantic nesting constraints
When we use a variety of browsers, we often find that even if we do not nest according to the standards will not have a big problem, which brings us to think: nesting errors in the end will not be a problem?
<div><h2>内容</div></h2>
Test results:
<p><div>内容</div></p>
Test results:
<ul><li>内容</li><div>内容</div></ul>
Test results:
<h2><div>内容</div></h2>
Test results:
<a href=""><a href="">内容</a></a>
Test results:
Through the chestnuts above, we summarize the following:
In fact, it is not reasonable to say that parsing errors are not reasonable, it should be said that the browser parses the results and we expect the results are inconsistent, but any nesting errors will not cause a great deal of errors in page rendering.
We know that if JS code is written with syntax errors, the browser's JS interpreter will refuse to execute and report errors, and the browser will do everything possible to present it when it encounters HTML code that does not conform to the syntax.
From the example above, we find that nesting elements in the elements of the element, or elements in the element, will cause all browsers to resolve errors, which is in fact the W3C specification of strict nesting constraints, strict nesting constraints must be observed, otherwise it will lead to all browser resolution errors.
Strict nesting constraint rules:
Semantic nesting constraints:
Each element basically has its own nesting rules (i.e., what the parent element can be and what the child element can be), in addition to strict nesting constraints, some rules are semantic nesting constraints, for semantic nesting constraints, if not adhered to, the page may be normal, but may also resolve errors, which is related to the fault tolerance mechanism described below.
Not every student does a legitimacy check after writing a page, so browser manufacturers have to let their browsers handle web pages in the most relaxed way possible, each browser kernel has a considerable amount of code dedicated to those vague html tags and nesting, and will guess how the front end wants to render the page, which is the browser's fault tolerance mechanism.
This is actually telling us that the HTML code we write does not conform to the W3C specification may eventually appear no different, but that is actually a browser fault tolerance mechanism, we have no reason to let ourselves in an easy attitude to code, the treatment of their own code should be meticulous, even if HTML5 is very broad-minded.
Originally we thought from HTML4 to XHTML is an era, and now from XHTML to HTML5, the birth of a new standard, we should open our hearts to embrace, not exclude.
If you pay attention or not, the standard is there, just increasing or not decreasing. W e should thank an organization like W3C for allowing browser vendors to work together to set new standards, putting aside their hostility. Otherwise, maybe you'll have to write your own set of code for a browser, as you did in the 1990s, when JS referenced an element.
Web standards will only make us eat better and sleep better, and new technologies or standards will drive us to be enthusiastic about coding, rather than repeating our work every day.
Add some common links to standards:
W3C International Station: http://www.w3.org/
W3C China: http://www.chinaw3c.org/
W3C HTML5: http://www.w3.org/TR/html5/