Please click the original link here By Richard Clark .
This paper is an original translation, and it also makes some simplification of the original text. This article follows Attribution Noncommercial Use Agreement 。
1、 Do not use section as a substitute for div
One of the most common mistakes people make in the use of tags is to randomly translate HTML 5 <section> Equivalent to <div> ——Specifically, it is directly used as a substitute (for style).
In XHTML or HTML4, we often see such codes:
<!-- HTML 4-style code --> <div id="wrapper"> <div id="header"> <h1>My super duper page</h1> <!-- Header content --> </div> <div id="main"> <!-- Page content --> </div> <div id="secondary"> <!-- Secondary content --> </div> <div id="footer"> <!-- Footer content --> </div> </div>
Now in HTML5, it will be like this:
<!-- Please do not copy these codes! This is wrong! --> <section id="wrapper"> <header> <h1>My super duper page</h1> <!-- Header content --> </header> <section id="main"> <!-- Page content --> </section> <section id="secondary"> <!-- Secondary content --> </section> <footer> <!-- Footer content --> </footer> </section>
This is not correct:* <section> It is not a style container *. The section element represents the semantic part of the content used to help build a document summary. It should contain a head. If you want to find an element to use as a page container (like HTML or XHTML style), consider writing the style directly to the body element, as Kroc Camen said. If you still need additional style containers, continue to use divs.
Based on the above ideas, the following are examples of correct use of HTML5 and some ARIA roles features (note that you may also need to add divs according to your own design)
<body> <header> <h1>My super duper page</h1> <!-- Header content --> </header> <div role="main"> <!-- Page content --> </div> <aside role="complementary"> <!-- Secondary content --> </aside> <footer> <!-- Footer content --> </footer> </body>
If you are still not sure which element to use, I suggest you refer to HTML5 sectioning content element flowchart
2、 Use header and hgroup only when necessary
Of course, it is meaningless to write labels that do not need to be written. Unfortunately, I often see headers and hgroups being misused pointlessly. You can read the two articles about the header and hgroup elements for a detailed understanding. The contents are briefly summarized as follows:
- The header element represents a set of introductory or navigational auxiliary text, which is often used as the head of a section
- When the header has a multi-layer structure, such as sub headers, subtitles, and various identification texts, use hgroup to combine h1-h6 elements as the header of the section
Abuse of header
The header can be used multiple times in a document, which may make this code style popular:
<!-- Please do not copy this code! The header -->is not needed here <article> <header> <h1>My best blog post</h1> </header> <!-- Article content --> </article>
If your header element contains only one header element, discard the header element. Since the article element has guaranteed that the header will appear in the document summary, and the header cannot contain multiple elements (as defined above), why write redundant code. Simply write it like this:
<article> <h1>My best blog post</h1> <!-- Article content --> </article>
<hgroup> Incorrect use of
On the topic of headers, I often see the wrong use of hgroup. Sometimes you should not use hgroup and header at the same time:
- If there is only one head
- If hgroup can work well by itself... Isn't that bullshit
The first question is generally as follows:
<!-- Please do not copy this code! The hgroup -->is not needed here <header> <hgroup> <h1>My best blog post</h1> </hgroup> <p>by Rich Clark</p> </header>
In this example, remove hgroup directly and let the head go.
<header> <h1>My best blog post</h1> <p>by Rich Clark</p> </header>
The second question is another unnecessary example:
<!-- Please do not copy this code! The header -->is not needed here <header> <hgroup> <h1>My company</h1> <h2>Established 1893</h2> </hgroup> </header>
If the only child element of the header is hgroup, then the header should do something? If there are no other elements in the header (such as multiple hgroups), you'd better remove the header directly
<hgroup> <h1>My company</h1> <h2>Established 1893</h2> </hgroup>
3、 Don't put all list type links in nav
With the introduction of 30 new elements in HTML5 (as of the release of the original text), our choice in constructing semantic and structured tags has become somewhat careless. In other words, we should not abuse hyper semantic elements. Unfortunately, nav is an example of such abuse.
The specification of the nav element is as follows:
The nav element represents the block in the page that links to other pages or other parts of the page; A block containing navigation links. Note: Not all links on the page need to be placed in the nav element - this element is intended to be used as the main navigation block. For example, there are many links in footer, such as service terms, home page, copyright notice page, etc. The footer element itself is enough to cope with these situations. Although the nav element can also be used here, it is generally considered unnecessary. [WHATWG HTML spec]( http://www.whatwg.org/specs/web-apps/current-work/complete/sections.html#the -nav-element)
The key word is "main" navigation. Of course, we can spray each other what is called "main" all day long. My personal definition is as follows:
- Main navigation
- On site search
- Secondary navigation (slightly controversial)
- On page navigation (such as long articles)
Since there is no absolute right or wrong, according to an informal vote and my own explanation, the following situation, whether you put it or not, I will not put it <nav> Medium:
- paging control
- Social links (although some social links are also the main navigation, such as "about" favorites ")
- Tags for blog posts
- Classification of blog posts
- Three level navigation
- Too long footer
If you are not sure whether to put a series of links in the nav, ask yourself: "Is it the main navigation?" To help you answer this question, consider the following first principles:
- If section and hx are also suitable, do not use nav - Hixie on IRC
- To facilitate access, will you add a link to the nav tag in a "shortcut"?
If the answer to these questions is "no", follow <nav> Make a bow and leave alone.
4、 Common errors of figure element
The correct use of figure and figcaption is really difficult to control. Let's take a look at some common mistakes. Not all pictures are figures. I told you not to write unnecessary code. The same is true of this mistake. I see many websites writing all the pictures in figure. For the sake of the picture, please don't add extra labels to it. You just make your own egg ache, but can't make your page content clearer.
In the specification, figure is described as
"Some flowing content sometimes has its own title description. It is generally referenced as an independent unit in the document flow“
This is the beauty of figure - it can be moved from the main content page to the sidebar without affecting the document flow.
These problems are also included in the HTML5 element flowchart Medium.
If the diagram is purely for presentation and is not referenced elsewhere in the document, it is absolutely not <figure> 。 Others depend on the situation, but at the beginning, you can ask yourself: "Does this picture have to be context sensitive?" If not, it may not be <figure> (Maybe it's a <aside> ）。 Continue: "Can I move it to the appendix?" If the two questions meet, it may be <figure> 。
Logo is not figure
Furthermore, logo is not applicable to figure. Here are some common code fragments:
<!-- Please do not copy this code! This is wrong --> <header> <h1> <figure> <img src="/img/mylogo.png" alt="My company" /> </figure> My company name </h1> </header> <!-- Please do not copy this code! This is also wrong --> <header> <figure> <img src="/img/mylogo.png" alt="My company" /> </figure> </header>
There is nothing to say. This is a very common mistake. We can spray each other to see if the logo should be H1 label, but this is not the focus of our discussion. The real problem is the abuse of the figure element. Figure should only be referenced in the document or surrounded by section elements.
I don't think your logo is likely to be quoted in this way. It's very simple. Do not use figure. You just need to do this:
<header> <h1>My company name</h1> <!-- More stuff in here --> </header>
Figure is not just a picture
Another common misconception about figure is that it is only used by pictures. Figure can be video, audio, chart, a quoted text, table, a code, a prose, and any combination of them or others. Don't limit figure to pictures. The responsibility of web standards is to accurately describe content with tags.
5、 Do not use unnecessary type attribute
This is a common problem, but not a mistake. I think we should avoid this style through best practices.
In HTML5, script and style elements no longer need the type attribute. However, these may be automatically added by your CMS, so it is not easy to remove them. But if you code manually or you can completely control your template, there is really no reason to include the type attribute. All browsers think that script is javascript and style is css style, so you don't need to go further.
<!-- Please do not copy this code! It's too redundant! --> <link type="text/css" rel="stylesheet" href="css/styles.css" /> <script type="text/javascript" src="js/scripts" /></script>
In fact, it only needs to be written as follows:
<link rel="stylesheet" href="css/styles.css" /> <script src="js/scripts" /></script>
Even the code specifying the character set can be omitted. Mark Pilgrim Dive into HTML5 In the chapter of semantics.
6、 Incorrect use of form attribute
HTML5 introduces some new attributes of form. The following are some precautions for use:
Boolean attribute
Some multimedia elements and other elements also have Boolean attributes. The rules mentioned here also apply.
Some new form attributes are boolean, which means that as long as they appear in the tag, the corresponding behavior has been set.
These attributes include:
autofocus autocomplete required
Frankly speaking, I seldom see such things. Take required as an example, the following types are common:
<!-- Please do not copy this code! This is wrong! --> <input type="email" name="email" required="true" /> <!-- Another example of an error --> <input type="email" name="email" required="1" />
Strictly speaking, it doesn't matter. As long as the browser's HTML parser sees the required attribute in the tag, its functions will be applied. But if you write in reverse equired="false" What about?
<!-- Please do not copy this code! This is wrong! --> <input type="email" name="email" required="false" />
The parser will still required The property is considered valid and executes the corresponding behavior, although you try to tell it not to. This is obviously not what you want.
There are three effective ways to use Boolean attributes. (The last two are only valid in xthml)
required required="" required="required"
The correct way to write the above example should be:
<input type="email" name="email" required />
