Problems that can be caused by HTML element nesting errors


May 03, 2021 12:37 HTML


Table of contents


Problems that can be caused by nesting errors

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?

Raise a chestnut 1: Start and end label nesting errors

<div><h2>内容</div></h2>

Test results:

Problems that can be caused by HTML element nesting errors

Take a chestnut 2:-lt;p-gt; elements nested in the -lt;div;gt; elements

<p><div>内容</div></p>

Test results:

Problems that can be caused by HTML element nesting errors

Take a chestnut 3: List elements .

<ul><li>内容</li><div>内容</div></ul>

Test results:

Problems that can be caused by HTML element nesting errors

Take a chestnut 4:-lt;h2-gt; element nesting-lt;div;gt; element

<h2><div>内容</div></h2>

Test results:

Problems that can be caused by HTML element nesting errors

Take a chestnut 5:-lt;a;gt; elements nested in -lt;a;gt; elements

<a href=""><a href="">内容</a></a>

Test results:

Problems that can be caused by HTML element nesting errors

Through the chestnuts above, we summarize the following:

  • Element start and end label nesting errors, pages can be resolved normally in most browsers, IE9 will have parsing errors
  • Embedding elements such as lt;div;gt; within the element causes all browser resolution errors
  • All browsers that embed elements such as lt;div;gt; all browsers can parse normally within the elements
  • Embedding the element within the element will result in an error in the resolution of all browsers
  • Inserting non-list brother elements, such as list elements, such as the list element, can result in an error in the resolution of IE6-IE7

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.

Strict nesting constraints, semantic nesting constraints

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:

  • a Elements may not be nested with interactive elements (lt;a;gt;, slt;button;, slt;select> etc.)
  • It can't be nested in the inside. slt;ol>;li>, slt;dl?gt;?lt;dt>/lt;dd;gt;,?lt;form>, etc
  • I haven't found any more at the time, some welcome to tell me

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.

The browser's fault tolerance mechanism

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.

Embrace the WEB standard

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/