Common 4 kinds of HTML5 error usage, how many mistakes did you use?

One, do not use section as a substitute for div one of the most common mistakes people make in tagging is to arbitrarily equate HTML5 with-specifically, directly as substitutes (for styling). In XHTML or HTML4, we often see this code: Page content Secondary content Footer content

And now in HTML5, it will be this: please do not copy this code! This is wrong!

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 is the correct example of using HTML5 and some ARIA roles features (note that you may also need to add a div depending on your own design) if you are still unsure of which element to use, then I suggest you refer to HTML5 sectioning content Element flowchart

It is of course meaningless to use headers and hgroup to write labels that do not need to be written. Unfortunately, I often see headers and hgroup being misused by nonsense. You can read the two articles about the header and the Hgroup element to make a detailed understanding of the contents of which I briefly summarize as follows: The header element represents a set of introductory or navigational nature of the auxiliary text, often used as a section of the head with a multi-layered structure, such as a sub-head, subtitle, various identity text, etc., use Hgroup to combine H1-H6 elements as the head of a section. Header abuse: Because the header can be used more than once in a document, this style of code may be popular: If your header element contains only one 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. Simply write it this way: on the subject 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 sub-head, if Hgroup can work well ... Is this nonsense? If the only child element of the header is Hgroup, then the header of the stem horse? If there are no other elements (such as multiple Hgroup) in the header, take the header straight away.

Third, do not put all the list of links in the Nav. With HTML5 introducing 30 new elements (as of the release of the original text), our choice of structuring semantic and structured tags has become somewhat less cautious. In other words, we should not misuse the hyper-semantic elements. Unfortunately, Nav is such an example of abuse. The specification of the NAV element is described as follows: The NAV element represents a chunk of the page that is linked to another page or other part of the page; 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 this is what I personally define: the main navigation station search for level two navigation (slightly disputed) navigation within the page (such as a long article)

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: Pagination control social links (although some social links are also the main navigation, such as "about" the "collection") blog posts of the label blog post Classification-level 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 equally appropriate, do not use Nav-hixie on IRC for easy access, will you add a link to the nav tag in a" Quick jump "? If the answer to these questions is no, then bow and leave alone.

The common mistakes of figure elements and the correct use of figcaption are indeed difficult to navigate. Let's take a look at some common mistakes, not all of which 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. If it is purely to render a diagram, nor is it referenced elsewhere in the document, it is definitely not. 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 (perhaps)." Continue: "Can I move it to the appendix?" "If two questions are met, then it may be. Logo is not a figure, there is nothing 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: figure is not just a picture 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.

Common 4 kinds of HTML5 error usage, how many mistakes did you use?