Avoid HTML5 six wrong usages

One, do not use section as a substitute for Div
One of the most common mistakes people make in label use is to arbitrarily HTML5 <section> equivalent to <div>--specifically, which is used directly as a substitute (for styling). In XHTML or HTML4, we often see this code:
<!--HTML 4-style code---
< div id= "wrapper" >
<div id= "Header" >
<!--Header Content--
</div>
<div id= "Main" >
<!--Page Content--
</div>
<div id= "Secondary" >
<!--secondary Content--
</div>
<div id= "Footer" >
<!--Footer Content--
</div>
</div>
And now in the HTML5, it will be this:
<!--Please do not copy this code! This is wrong! -
< section id= "wrapper" >
<!--Header Content--
<section id= "Main" >
<!--Page Content--
</section>
<section id= "Secondary" >
<!--secondary Content--
</section>
<footer>
<!--Footer Content--
</footer>
</section>
This is not used correctly:<section> is not a style container. The section element represents the semantic part of the content that is used to help build a document profile. It should consist of a head. If you're looking for an element to use as a page container (like HTML or XHTML style), consider writing the style to the BODY element, as Kroc Camen says. If you still need an extra style container, continue with the Div bar.
Based on the above thought, here's an example of the correct use of HTML5 and some ARIA roles features (note that depending on your own design, you may also need to add div)
< body>
<!--Header Content--
<div role= "Main" >
<!--Page Content--
</div>
<aside role= "Complementary" >
<!--secondary Content--
</aside>
<footer>
<!--Footer Content--
</footer>
</body>
If you are still unsure of which element to use, then I suggest you refer to HTML5 sectioning content element flowchart
Second, use headers and hgroup only when needed
It's pointless to write labels that don't need to be written. Unfortunately, I often see headers and hgroup being misused by nonsense. You can read a detailed understanding of the two articles on the header and Hgroup elements, which I briefly summarize as follows:
The header element represents a set of introductory or navigational auxiliary text that is often used as the head of a section
When the head has a multilayer structure, such as a sub-head, subtitle, a variety of logo text, etc., use Hgroup to combine H1-H6 elements as the head of a section
Misuse of headers
Because the header can be used multiple times in a document, this style of code may be popular:
<!--Please do not copy this code! The header is not required here--
< article>
<!--article Content--
</article>
If your header element contains only a single header element, discard the header element. Since the article element has ensured that the head appears in the document profile, and the header cannot contain multiple elements (as defined above), then why write extra code. The simple point is that it's OK:
< article>
<!--article Content--
</article>
Incorrect use of On the theme of headers, I also often see the hgroup of the wrong use. Sometimes hgroup and headers should not be used at the same time:
If there is only one child head
If Hgroup himself can work very well ... Is this nonsense?
The first question is usually this:
<!--Please do not copy this code! Hgroup is not required here--
< header>
<p>by Rich clark</p>
In this example, take the hgroup directly and let the heading fruit run.
< header>
< h1>my Best blog post< P>by Rich clark</p>
The second problem is another unnecessary example:
<!--Please do not copy this code! Header is not required here--
< header>
If the only child element of the header is Hgroup, do you want the header to be a horse? If there are no other elements (such as multiple Hgroup) in the header, take the header straight away.
< hgroup>
For more examples and explanations of Third, do not put all the list-style links in the Nav
As HTML5 introduced 30 new elements (as of the release of the original text), our choice to construct semantic and structured tags became somewhat less cautious. In other words, we should not misuse the hyper-semantic elements. Unfortunately, Nav is such an example of abuse. The canonical description of the Nav element is as follows:
The Nav element represents a block in a page that links to another page or to another part of the page, and 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 often many links in footer, such as terms of service, home page, copyright notice page, and so on. The footer element itself is sufficient to cope with these situations, although the NAV element can also be used here, but usually we think it is unnecessary.
The key word is "primary" navigation. Of course, we can spray each other all day. What is called "the main". And that's what I personally define:
The main navigation
Search in the station
Second-level navigation (slightly controversial)
In-page navigation (e.g. long articles)
Since there is no absolute right or wrong, so according to an informal vote and my own explanation, the following situation, whether you put it or not, I do not put in <nav>:
Paging control
Social links (although some social links are also the main navigation, such as "about" "Favorites")
Tags for blog posts
Categories of blog Posts
Level Three navigation
A long footer.
If you're not sure if you want to put a series of links in Nav, ask yourself: "Is it the main navigation?" "To help you answer this question, consider the following first principles:
If using section and HX are also appropriate, do not use Nav-hixie on IRC
For easy access, would you like to add a link to this nav tag in a "Quick jump"?
If the answer to these questions is "no", then bow with <nav> and leave alone.
Iv. common errors in Figure elements
The correct use of figure and figcaption is indeed difficult to navigate. Let's take a look at some common mistakes,
Not all the pictures are figures
Above, I have told you not to write unnecessary code. The same is true of this mistake. I see a lot of websites that write all the pictures. For the sake of the picture, please do not add extra tags to it. You just make your own eggs ache, and not make your page content clearer.
The specification describes a figure as "some flowing content, sometimes with a caption that contains itself." It is generally referenced as a separate 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 flow of the document.
These issues are also included in the previously mentioned HTML5 element flowchart.
It is definitely not <figure> if it is purely for rendering and not referencing elsewhere in the document. Others are subject to availability, but at the outset you can ask yourself: "Does this picture have to do with context?" "If not, it may not be <figure> (maybe a <aside>)." Continue: "Can I move it to the appendix?" "If two questions are met, it may be <figure>.
The logo is not a figure
Further, the logo does not apply to figure. Here are some of my common code snippets:
<!--Please do not copy this code! This is wrong--
< header>
<figure>

</figure>
My Company Name
<!--Please do not copy this code! This is also wrong--
< header>
<figure>

</figure>
There's nothing left to say. This is a very common mistake. We can give the logo whether it should be H1 label and spray each other to the cows have finished home, but this is not the focus of our discussion. The real problem is the misuse of figure elements. 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. Very simple, do not use figure. You just have to do this:
< header>
<!--more stuff on here--
It's not just pictures.
Another common misconception about figure is that it is only used by images. Figures can be video, audio, graphs, quotes, tables, a piece of code, a piece of prose, and any combination of them or any other. Don't confine the figure to the picture. The responsibility of web standards is to accurately describe content with tags.
V. Do not use the unnecessary type attribute
This is a common problem, but it's not a mistake, and I think we should avoid this style with best practices.
In HTML5, the script and style elements no longer require the type attribute. However, these are likely to be added automatically by your CMS, so it's not easy to remove them. But if you're coding manually or you can control your template completely, there's really no reason to include the type attribute. All browsers think that scripting is JavaScript and style is CSS style, you don't have to superfluous anymore.
<!--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:
< link rel= "stylesheet" href= "Css/styles.css"/>
< script src= "js/scripts"/></script>
Even code that specifies a character set can be omitted. Mark Pilgrim An explanation in the semantic chapter of dive into HTML5.
Vi. incorrect use of form properties
HTML5 introduces some new properties of the form, here are some caveats to use:
Boolean property
Some multimedia elements and other elements also have Boolean properties. The same applies to the rules mentioned here.
Some of the new form properties are Boolean, meaning that they appear in the label so that the corresponding behavior is set. These properties include:
Autofocus
AutoComplete
Required
Frankly speaking, I seldom see such a thing. Taking required as an example, the following is common:
<!--Please do not copy this code! This is wrong! -
< input type= "email" name= "email" required= "true"/>
<!--Another example of the error--
< input type= "email" name= "email" required= "1"/>
Strictly speaking, this is not a major hindrance. The browser's HTML parser will be applied whenever it sees that the required attribute appears in the tag. But what if you write equired= "false" in turn?
<!--Please do not copy this code! This is wrong! -
< input type= "email" name= "email" required= "false"/>
The parser still treats the required property as valid and performs the corresponding behavior, although you try to tell it not to execute it. This is obviously not what you want.
There are three effective ways to use Boolean properties. (the latter two are only valid in Xthml)
Required
Required= ""
Required= "Required"
The correct wording of the above example should be:

<input type= "Email" name= "email" required/>

Avoid HTML5 six wrong usages