One of the most common mistakes people make in tag usage is to HTML5 <section> equivalent to <div>--specifically, 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" >And now in the HTML5, it would be this:
<!--Please do not copy this code! This is wrong! --> <section id= "wrapper" >This is not the correct use:<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 contain a head. If you're looking for 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 says. If you still need an extra style container, continue using the div.
Based on these ideas, the following are the correct examples of using HTML5 and some ARIA roles features (note that you may also need to add div according to your own design)
<body>Second, use header and Hgroup only when needed
Writing labels that don't need to be written is of course meaningless. Unfortunately, I often see headers and hgroup being misused by the senseless. You can read the two articles about header and Hgroup elements for a detailed understanding of the contents, which I summarize briefly as follows:
Abuse of header
Because headers can be used more than once in a document, this style of code may be welcome:
<!--Please do not copy this code! Header--> <article>If your header element contains only one header element, discard the header element. Since the article element has guaranteed that the head will appear in the document profile, and the header cannot contain more than one element (as defined above), then why write the extra code. The simple point of writing this is OK:
<article>On the subject of headers, I also often see Hgroup error usage. Sometimes you should not use both Hgroup and headers:
The first question is generally like this:
<!--Please do not copy this code! Hgroup-->In this case, directly remove hgroup, let heading fruit Rush bar.
The second problem is another unnecessary example:
<!--Please do not copy this code! Header-->If the only child element of the header is Hgroup, then the header is the dry god horse? If there are no other elements in the header (such as multiple Hgroup), just take off the header.
Third, do not put all the list of links in the Nav
As HTML5 introduced 30 new elements (as of the original release), our choice of structuring semantically and structured labels has become somewhat imprudent. In other words, we should not misuse the hyper-semantic elements. Unfortunately, Nav is an example of such abuse. The specification for the NAV element is described as follows:
The nav element represents a chunk of a page that is linked to another page or other part of the page, and a block that contains a navigation connection.
Note: Not all links on the page need to be placed in the nav element-this element is intended to be used as the primary navigation block. For example, there are often a number of 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 NAV elements can also be used here, but usually we do not consider it necessary.
WHATWG HTML Spec
The key word is " main " navigation. Of course we can spray each other all day. What is called "main". And I personally define this:
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, I will not put in <nav>:
If you're not sure whether you want 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 the answer to these questions is "no", then bow to <nav> and leave alone.
iv. Common errors in Figure elementsThe correct use of figure and figcaption is indeed difficult to manage. Let's take a look at some common mistakes,
Not all the pictures are figure
Above, I have told you not to write unnecessary code. The same is true of this mistake. I see a lot of websites that have all the pictures written figure. For the sake of the picture, please don't add any extra labels to it. You just make your own egg ache and not make your page more clear.
The specification describes figure as "some of the flow of content, sometimes with a title description contained in itself." It is generally used as a standalone unit reference 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 HTML5 element flowchart mentioned earlier.
It's definitely not <figure> if it's just a graph to render, and it's not referenced elsewhere in the document. Other depending on the situation, but at the outset you can ask yourself: "Does this picture have to be contextual?" "If not, it may not be <figure> (maybe a <aside>)." Continue: "Can I move it to the appendix?" "If all two problems are met, then it may be <figure>."
The logo is not figure
Further, the logo does not apply to figure. Here are some of my common code snippets:
<!--Please do not copy this code!--><!--Please do not copy this code! It's also wrong.-->There's nothing more to say. This is a common mistake. We can give the logo whether it should be H1 label and spray each other to the cows are 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 a document, or surrounded by a section element. I don't think your logo is likely to be quoted in this way. Very simple, please 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 pictures. Figure can be video, audio, charts, a quote text, a table, a piece of code, a piece of prose, and any combination of them or any other. Don't limit figure to pictures. The responsibility of web standards is to accurately describe content with tags.
v. Do not use unnecessary type attributesThis is a common problem, but it's not a mistake, and I think we should avoid that style by best practices.
In HTML5, the Type property is no longer required for script and style elements. However, these are likely to be automatically added to your CMS, so it's not easy to remove. But if you're hand coded or you can control your template, there's really no reason to include the type attribute. All browsers think the script is JavaScript and the style is CSS style, you don't have to do it any more.
<!--Please do not copy this piece of 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, you just have to write this:
<link rel= "stylesheet" href= "Css/styles.css"/> <script src= "js/scripts"/></script>Even code that specifies the character set can be omitted. Mark Pilgrim An explanation in the semantic chapter of Dive into HTML5 .
wrong use of form propertyHTML5 introduces some of the new properties of the form, and here are some caveats to use:
Boolean Properties
Some multimedia elements and other elements also have Boolean properties. The rules mentioned here also apply.
Some of the new form attributes are Boolean, meaning that they appear in the label, ensuring that the corresponding behavior has been set. These properties include:
Frankly speaking, I rarely see such a thing. Taking required as an example, the following are common:
<!--Please do not copy this code! This is wrong! --> <input type= "email" name= "email" required= "true"/> <!--Another wrong example--> <input type= " Email "name=" required= "1"/>
Strictly speaking, this is not a major obstacle. The browser's HTML parser simply sees that the required attribute appears in the tag, and its functionality is applied. 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 appropriate behavior, although you try to tell it not to execute. It's obviously not what you want.
There are three effective ways to use Boolean properties. (the latter two are only valid in Xthml)
The correct formulation of the above examples should be:
<input type= "Email" name= "email" required/>
To Ian Devlin, Derek Johnson, Tady Walsh, the HTML5 Gallery curators, and the HTML5 doctors for their Article.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
