Home > Developer > Web Develop
The recent group of HTML5 label Learning, the method is that everyone selects a few tags, their own first to learn, and then to explain to you. This process is still very rewarding. But now HTML5 is still in the draft stage, and some of the new labeling elements are often explained, Even the label to move out is also very frequent (such as Hgroup), while the existing large Web portal in the use of HTML5 also have no good examples can be consulted, so that everyone's learning process more groping. Here is an article I saw in the html5doctor above, at present everybody ignorant stage, Perhaps it would be easier to read the master's explanation. As a result of Caishuxueqian, many do not understand the place may just do a literal translation, the wrong place also ask everyone to advise.
The following is attached to the original address: avoiding common HTML5 Mistakes Author: Richard Clark, where you have questions, you can check English.
In this article, I will share with you the small errors and bad practices of the HTML5 build page, and let us avoid these errors in future work.
Don't define a style with <Section> as a simple container
One of the mistakes we often see is to arbitrarily replace the <div> tag with a <section> tag, especially as a <div> that surrounds the container with <section>. In XHTML or HTML4, we will see code similar to the following:
Now I see the following code look:
Visually, the above example is wrong:<section> not a container .<section> element is a semantic section that helps to build a document outline. It should contain a caption. If you are looking for an element that can contain pages (whether HTML or XHTML), it is common practice to define a style directly on the <body> tag, as Kroc Camen describes, if you need additional elements to define the style, use <DIV> As Dr Mike explains, Div is not extinct, and if there are no other more appropriate, Div may be the most appropriate choice for you.
Remember this, here we have revised the example above, by using two new characters. (Whether you need extra <div> depends on your design.) ）
If you're still unsure which element is more suitable, I suggest you check out the HTML5 sectioning content element flowchart to keep you moving forward.
Use
It is unreasonable to write some unwanted phenomena when using tags. Unfortunately, it is often found that people use
Over-use
You certainly know that in a document you can use multiple
If your
In this topic of the title, you often see error cases using
The first scenario looks like this:
In this case, the
The second case also contains tags that they do not need.
Why do we need an extra
Do not place all of the link lists on the <nav> tab
Of the 30 new elements added to HTML5 (as we write this article), when we build more semantically structured tags, our choices become too rich. That is to say, we are going to abuse these super-semantic tags that we now offer to us .<nav> is a very tragic example. The description in the specification is this:
Thenav element represents a, section of a page, links to other pages, or to parts within the page:a sections with Navigation links. Note:not all groups of the links on a page need to being in a nav element-the element are primarily intended for sections that consist of major navigation blocks. In particular, it's common for footers to has a short list of links to various pages of a site, such as the terms of ser Vice, the home page, and a copyright page. The footer element alone is sufficient for such cases; While a NAV element can being used in such cases, it is usually unnecessary.
WHATWG HTML Spec
The key word in this is "important" navigation. We may have different definitions of "important", but my understanding is:
Although there is no right or wrong point, but according to my understanding and a poll made me feel that under these circumstances, I will not use the <nav> tag:
If you are not sure whether to use <nav>, then ask the following questions: "Is the person a primary link?" "You can answer the question you just made based on several factors:
If the above answer is "no", it may not be appropriate to use <nav>.
Errors in <figure> elements
<figure> and often <figcaption> with it, it is difficult to grasp the label, the following is often seen some small errors.
Not all pictures are figures (note: More difficult to understand, image= pictures, figure= graphics)
Before, I once said don't write those unwanted tags. This error is also the same. I often see that every picture on a website has a <figure> tag. These additional tags will not bring you any benefits, but also add to your own intensity and make your content harder to understand.
The interpretation of <figure> in the specification is as follows: "Some stream content, which can have a title, self-contained, and usually as a unit independent of the inner document flow. "There is a perfect representation that it can be removed from the main content-for example, in the sidebar, without affecting the flow of documents."
It is not necessary to use <FIGURE> if it is just a picture of the class and does not have anything to do with the other content in the document. " Does this picture need to explain the content of the context? "If the answer is no, it may not be <figure> (probably <aside>)," Can I move it to the appendix? If the answer to both questions is yes, it could be <figure>.
Your logo is not a <figure>
Extend the above to your logo as well. Here are two sets of code snippets I've found that are regular:
There is no need to say anything, this is a very obvious mistake, maybe you think we are talking about the logo in the H1 tag, but we do not discuss this issue here. What confuses us is the <figure> element. <figure> tags are used only when there is a context to explain or be surrounded by <section>. What I'm saying here is that your logo may rarely be used in this case. It's simple, so don't do it, you just need to look like this.
Figure can only be used on the label of misunderstanding
Another misconception about <figure> is that we generally think that it can only be used on images. In fact this is not the case, it can be used in <video><audio>, an icon (such as <svg>,), a reference, a table, a piece of code, a piece of prose, or any combination of those related. Do not confine your <figure> tags to the image alone. The task of our web-maker is to use labels to describe content more accurately.
Here is a more in-depth explanation <figure> article I wrote about <figure> it's worth reading.
Do not use those unnecessary type attributes
This may be our most common problem, they are not real mistakes, but I think our best practice is to try to avoid this pattern.
In HTML5, we do not need to add the type attribute to <script> and <script>, if it is painful to remove these from the CMS default content, Then you can delete them when you manually encode them or you can completely control your template when you write them down. Because all browsers will parse <script> into JavaScript and <css> tags are CSS, you no longer need that type attribute:
Now we can write the following:
You can also omit the encoding settings. Mark Pilgrim An explanation in the semantic chapter of dive into HTML5.
Do not include the wrong form properties
You may find that
Boolean property
Several of the newly introduced tag properties are Boolean, and their tag behavior is basically close. These properties include:
Frankly, the following situation is not common to me, but we take the example from required as follows:
Basically, this piece of code doesn't hurt. The client's parsing of the HTML will take effect when it encounters the required tag attribute. But what happens when we change the code and enter Required= "false"?
The required attribute is still encountered when parsing, although the behavior you wish to join is false, it will still be parsed into true.
There are three reasonable ways to get the Boolean value into effect. (The second and third option is only required when you write XHTML parsing)
Our example above can be written as follows:
Common pitfalls of "go" HTML5 tags
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
