XHTML tutorial: The difference between Transitional and Strict_HTML/Xhtml_Web page production

In fact, XHTML 1.0 is divided into two types (three types if you add Frameset DOCTYPE, which will not be discussed in this article), Transitional and Strict DOCTYPEs. And HTML 4.01 also has the same documentation statement.
In today's promotion of Web standards, those who advocate Web standards often say that XHTML is more strict than HTML. Of course, it is true in a sense. For example, it requires all tags to be closed and all attributes to be quoted. But in fact, XHTML 1.0 is divided into two types (three types if you add Frameset DOCTYPE, which will not be discussed in this article), Transitional and Strict DOCTYPEs. And HTML 4.01 also has the same documentation statement.

You can see the meaning literally: Transitional DOCTYPEs are just to achieve the transition from the old era to the new era, and Strict DOCTYPEs are the default document declaration, which is very important for constructing HTML 4.01 and XHTML 1.0 is applicable.
Using Transitional DOCTYPE is usually because the code contains too many old writing methods, and it is difficult to completely convert to Strict DOCTYPE at once. But Strict DOCTYPE should be your goal. It encourages and even sometimes forces you to separate structure from presentation and write all presentation layer code in CSS. HTML 4 Document Type Definition:

This HTML 4.01 Strict DTD does not include presentation layer attributes and tags. W3C will gradually phase out these attributes and tags. You can completely use style sheets to achieve this. You should use a Strict DTD. For support of presentation properties and tags, use a Transitional DTD.

Using Strict DOCTYPE also has the advantage that it allows browsers to use their most strict and (to a certain extent) most standards-compliant mode to render the page.
Tommy Olsson explains the benefits of using Strict very well in the Web Standards Group’s Ten questions for Tommy Olsson:

I think using Strict DTD, whether it is HTML 4.01 Strict or XHTML 1.0 Strict, is far more important than discussing whether to use HTML or XHTML. It represents the quality of the future Internet. It separates structure and presentation, making maintaining a site very easy.

For those who are new to web standards and correct, semantic structures, it is important to understand the difference between Transitional and Strict DOCTYPEs. For a more detailed list, please refer to: XHTML: Differences between Strict & Transitional, Comparison of Strict and Transitional XHTML and XHTML1.0 Element Attributes by DTD.
For those who are preparing to move to Strict, there are some differences between the two that may cause developers to make mistakes, which I will talk about next. Tags not supported under Strict DOCTYPEs center font iframe srike u Properties not supported under Strict DOCTYPEs align (table-related support: col, colgroup, tbody, td, tfoot, th, thead, and tr) language background bgcolor border (table support) height (supported by img and object) hspace name (supported in HTML 4.01 Strict, not supported by form and img in XHTML 1.0 Strict) noshade nowrap target text, link, vlink, and alink vspace width (img, object, table, col, and colgroup are supported) The difference between content models
The content model of an element type describes what instances of the element type can be contained. At this point, the biggest difference between the two document declarations is that blockquote, body, and form elements can only contain block-level elements, such as: Text and images are not allowed to be included directly in the body and must be included in block-level elements such as p or div. The input element cannot be directly one level below the form element. The text within the blockquote element must be contained by block-level elements such as p or div. Leave all performance to CSS and adhere to Strict standards
In the process of transitioning to Strict DOCTYPEs, it is more effective to know what each element does than what each element looks like.
Think about structure and semantics first, worry about performance later.