Home > Developer > Web Develop
Recently in the group to carry out the study of HTML5 tags, the method is that everyone selected a few tags, their own first to learn, and then give you to explain. This process is still very rewarding. But now HTML5 is still in the draft stage, some of the new labeling elements of the interpretation is also often change, even the tag to join/move out is also very frequent (such as Hgroup), while the existing large Web portal in the use of HTML5 is also not a good example 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, may see the master's explanation will be easier to understand. 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, there are questions about where 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 containerOne 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:
<!--HTML 4-style Code -Now I see the following code look:
<!--Don ' t copy this code! It ' s wrong! -Intuitively, the above example is the wrong:<section> is not a container. The <section> element is a semantic section that helps 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.
UseIt is unreasonable to write some unwanted phenomena when using tags. Unfortunately, it is often found that people use
You certainly know that in a document you can use multiple
<!--Don ' t copy this code! No need for headers here -If your
<article>On this topic of the title, you often see error cases using
The first scenario looks like this:
<!--Don ' t copy this code! No Need for Hgroup -In this case, the
<Header>The second case also contains tags that they do not need.
<!--Don ' t copy this code! No need for headers here -Why do we need an extra
<Hgroup>In the 30 new elements of HTML5 (as we write this article), our choices become too rich when we build more semantic \ Structured tags. That is to say, we may abuse these super-semantic tags that we now offer to us. <nav> is a very tragic example. The description in the specification is this:
The nav element represents a section of a page, links to other pages or to parts within the page:a sections with Navig Ation 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 this a major 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 a 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:
<!--Don ' t copy this code! It ' s wrong! -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.
<Header>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 of these related combinations. 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 of the <figure> article I wrote <figure> about, well worth reading.
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:
<!--Don ' t copy this code! It ' s attribute overload! -Now we can write the following:
<Linkrel= "stylesheet"href= "Css/styles.css"/>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 propertiesYou may find that
Boolean propertySeveral 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:
<!--Don ' t copy this code! It ' s wrong! -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"?
<!--Don ' t copy this code! It ' s wrong! -The required attribute is still encountered when parsing, although the behavior you wish to join IS "false" and it will still be parsed as "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:
<inputtype= "Email"name= "Email"Required/> Summarize
For me, I can't show all the crappy code patterns here, but these are all the things that we often encounter.
Original URL: http://ued.sina.com/?p=726
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
