X/HTML5 and XHTML2_html5 Tutorial Tips-H5 Tutorial-php.cn

After understanding the progress of XHTML 2, let’s take a look at the progress of X/HTML 5.
What’s cool about X/HTML 5
Conception of Chapter Elements
X/HTML 5 introduces new elements for dividing web pages into chapters. These components help search engines and accessibility tools better understand the content of the page. Use these new elements to make labels more readable.
The idea of chaptered content is cool! But take a look at why using chapter technology isn't cool enough.
Dialogue elements
Conversation element is used to represent a conversation. It includes a dt element used to define the speaker and a dd element representing the content of the speaker's speech. For example:

figrue element
Mastheads are often used in media objects (photos, illustrations, charts, etc.) in printed publications (textbooks, newspapers, magazines, etc.). So far, Web markup languages have no constructs that can produce this effect. The figrue element has a legend child element that can be used to specify the header of the image. For example:
XML/HTML code

m element The
m element represents a section of text that is marked or highlighted. This is very useful when displaying search keywords in dynamic web pages. At this time, the keywords in the page can be marked using the m element. For example, in response to the user's search for the keyword snow, the web page can generate the following content:
XML/HTML code

A snowman is a man-like sculpture constructed out of snow.

The input element has been enhanced
The input element function has been enhanced to support email, url, data-related, time-related, and numeric data types. This means that more verification functions can be completed on the client side.
Open process
The development process of X/HTML is much more open than XHTML 2. Everyone can participate in the X/HTML 5 creative process.
The fly in the ointment of X/HTML 5
Usage of chapter elements
The idea of using chapter elements is good, but it seems a bit cumbersome in X/HTML 5 applications. Some explanations may even leave you more confused. For example:
The aside element represents a part of the page content. It is related to the content before and after the aside element. It can be regarded as an independent part of the content. These components are often used in sidebars in printing technology.
Aren’t div elements with role attributes more extensible and easier to understand?
Another mentioned chapter element is nav, which is used to represent links to other pages in the page. Do we really need the nav element? The nl element in XHTML 2 accomplishes this task better.
The deficiencies in HTML 4 and XHTML 1 will still exist in future specifications
Because X/HTML attempts to provide backward support, deficiencies in HTML 4 and XHTML 1 will still exist in X/HTML 5. Specifications need not be backwards empty; instead, client software should provide backward compatibility by supporting multiple specifications.
X/HTML 5 does not follow the X/HTML 5 manual
X/HTML 5 is designed to be backward compatible with HTML 4 and XHTML 1. Currently big, acronym, u and tt are not part of this specification, but other elements such as i and samll have redefined semantics. For example, i and small are defined in the HTML 4.01 specification as follows:
i: Make the text italic
small: render text in "small" font
In X/HTML 5, i and small have new meanings:
The i element uses different ways to express a piece of text or a paragraph that is different from the main text, such as classification design, technical terms, idioms in foreign languages, an idea, opinion, ship name or other needs in printing technology Renders text in italics. .
The small element presents small print fonts (parts of the document that explain legal constraints, such as copyright or existing drawbacks) and comments.
This breaks backwards compatibility with HTML 4 and XHTML 1 by redefining the meaning of i and small. This is because backward compatibility should mean that the HTML 5 user agent (browser) should be consistent with the HTML 4 user agent when rendering HTML 4 documents. Therefore, if HTML 5 emphasizes backward compatibility, structures that have little meaning in HTML 4 also have little meaning in HTML 5.
No way? Is the font element still supported?
Yes, X/HTML 5 still supports the font element if the developer uses a WYSIWYG editor. Is there any justification for this? Can WYSIWYG editors avoid using fonts?
WYSIWYG signature
Documents generated using a WYSIWYG editor must contain the following WYSIWYG signature in the head element:
XML/HTML code

Or:
XML/HTML code

What is the reason for doing this? Some kind of mark of shame? Does it tell the browser to prepare for the worst because this document was generated with a WYSIWYG editor? So, what if only part of the document is completed using WYSIWYG tools?
Supports predefined class names
Predefined class names are semantic CSS class names reserved in X/HTML 5 user agents. In the following example, copyright is a predefined class name:
XML/HTML code

One problem with predefined class names is that it doesn’t make sense to write them like this:
XML/HTML code

Only writing this way makes sense:
XML/HTML code

Rewriting the class attribute makes it difficult to explain the specific meaning of the structure. For example, what does the following code mean:
XML/HTML code

Predefined class names also limit the developer's freedom in using class names. Similarly, if the developer uses a non-predefined class name now, but one day the class name becomes a predefined class, what will happen first? Does this change the semantics of the developer's previous content?
HTML 5 v.s. XHTML 5
In an attempt to finally resolve the HTML vs. XHTML debate, the X/HTML 5 specification makes things harder to understand. Indeed, the X/HTML 5 specification does say that "generally speaking, developers can also use XML directly in the Web", even though the W3C has been working hard for the future application of XML in the Web.
The development process is too rushed
X/HTML 5 is in response to the W3C's delay in updating HTML 4 and XHTML 1. As a result, the development process for X/HTML 5 has been a bit rushed, with the specification feeling like it came out of nowhere and then followed quickly. Even developers directly involved feel that the standardized development process is a bit unrealistic.
Competition for the next generation of markup languages
X/HTML 5 and XHTML 2 are both competing to replace HTML 4 and XHTML 1. Even in the early stages of development, some browser vendors have stated their preference for both specifications. This has polarized Web standards organizations due to the urgency and closed nature of the deliberations. As both specifications progress, more development resources and market capital will be invested in one of them, all of which will lead to a "standards" war.
Each of us is the setter of this standard, because the Web belongs to everyone, and only an honest, open debate can ensure that the best standard wins.
Note: For the convenience of reading, the article abbreviates "HTML 4.x/XHTML 1.x" as "HTML 4 and XHTML 1"
Original link: http://www.dudo.org/article.asp?id=249