In fact, XHTML1.0 is divided into two types (three in addition to FramesetDOCTYPE, which will not be discussed in this article), Transitional and Strict DOCTYPEs. HTML4.01 also has the same document declaration. Today, those who advocate Web standards often say that XHTML is better than HTML in fact, XHTML 1.0 is divided into two types (three in the case of Frameset DOCTYPE, which will not be discussed in this article ), transitional (Transition type) and Strict (Strict) DOCTYPEs. In addition, HTML 4.01 has the same document declaration.
Today, those who advocate Web standards often say that XHTML is stricter than HTML. Of course, in a sense, it is true, for example, it requires that all tags be closed and all attributes are enclosed in quotation marks. But in fact, XHTML 1.0 is divided into two types (three in the case of Frameset DOCTYPE, which will not be discussed in this article), Transitional (Transitional type) and Strict (Strict) DOCTYPEs. In addition, HTML 4.01 has the same document declaration.
It can be seen literally that Transitional DOCTYPEs is only used to achieve the transition from the old age to the new era, and Strict DOCTYPEs is the default Document declaration, applicable to the construction of HTML 4.01 and XHTML 1.0.
The use of Transitional DOCTYPE is generally because the Code contains too many outdated writing methods, and it is difficult to fully convert to Strict DOCTYPE at once. But Strict DOCTYPE should be your goal. It encourages or even sometimes forces you to separate the structure from the presentation, and write the code at the presentation layer in CSS. HTML 4 Document Type Definition:
This HTML 4.01 Strict DTD does not contain presentation layer attributes and tags. W3C will gradually remove these attributes and tags, which can be implemented using style sheets. You should use the Strict DTD. To support performance Layer attributes and labels, use the Transitional DTD.
Another benefit of using Strict DOCTYPE is that browsers can render pages in the strictest (to some extent) Standard-compliant mode.
Tommy Olsson elaborated on the advantages of using Strict in the article Ten questions for Tommy Olsson of the Web Standards Group:
I think using Strict DTD, whether it is HTML 4.01 Strict or XHTML 1.0 Strict, is far more important than discussing whether using HTML or XHTML. It represents the quality of the future Internet. It separates the structure and performance, making it easy to maintain a site.
For those who are new to web standards and the correct and semantic structure, it is important to recognize the differences between Transitional and Strict DOCTYPEs. For more details, see XHTML: Differences between Strict & Transitional, Comparison of Strict and Transitional XHTML and XHTML1.0 Element Attributes by DTD.
For those preparing to move toward Strict, there are some differences between the two, which may lead to developers' mistakes. I will talk about them later. Attributes not supported by TAG center font iframe srike u under Strict DOCTYPEs align (Table-related support: col, colgroup, tbody, td, tfoot, th, thead, and tr) language background bgcolor border (table supported) height (img and object supported) (supported in HTML 4.01 Strict, not in form and img of XHTML 1.0 Strict) noshade nowrap target text, link, vlink, and content model differences with alink vspace width (supported by img, object, table, col, and colgroup)
The Content Model of the element type describes what type of element instance can be included. At this point, the biggest difference between the two types of document declarations is that blockquote, body, and form elements can only contain block-level elements, such as text and images that cannot be directly included in the body, the input element must be contained by block-level elements such as p or p. It cannot be directly the text in the blockquote element of form, must be included in block-level elements such as p or p. All the performances must be handed over to CSS and Strict standards must be adhered.
In the transition to Strict DOCTYPEs, understanding what each element is doing is much more effective than knowing what each element looks like.
Consider structure and semantics first, and then worry about performance.
