Common HTML5 tag misuse cases in front-end development, and front-end html5 tag Cases
I. Do not use section as a substitute for div
One of the most common errors in tag use is to arbitrarily use HTML5 <section> as <div>-specifically, it is directly used as a substitute (for style ). In XHTML or HTML4, we often see the following code:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<! -- HTML 4-style code --> <Div id = "wrapper"> <Div id = "header"> <H1> My super duper page <! -- Header content --> </Div> <Div id = "main"> <! -- Page content --> </Div> <Div id = "secondary"> <! -- Secondary content --> </Div> <Div id = "footer"> <! -- Footer content --> </Div> </Div> |
But now in HTML5, it will be like this:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<! -- Do not copy the code! This is wrong! --> <Section id = "wrapper"> <Header> <H1> My super duper page <! -- Header content --> </Header> </Section> <section id = "main"> <! -- Page content --> </Section> <Section id = "secondary"> <! -- Secondary content --> </Section> <Footer> <! -- Footer content --> </Footer> |
This is incorrect:<Section> it is not a style container.. The section element represents the semantic part of the content used to help build the document summary. It should contain a header. If you want to find an element used as a page container (like HTML or XHTML style), write the style directly to the body element, as Kroc Camen said. If you still need additional style containers, continue using div.
Based on the above ideas, the following are examples of correct use of HTML5 and some ARIA roles features (note that you may also need to add div based on your own design)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<Body> <Header> <H1> My super duper page <! -- Header content --> </Header> <Div role = "main"> <! -- Page content --> </Div> <Aside role = "complementary"> <! -- Secondary content --> </Aside> <Footer> <! -- Footer content --> </Footer> </Body> |
If you still cannot determine which element to use, I suggest you refer to HTML5 sectioning content element flowchart
2. Use the header and hgroup only when necessaryWriting tags that do not need to be written is of course meaningless. Unfortunately, I often see meaningless misuse of headers and hgroups. You can read the two articles about the header and hgroup elements for a detailed understanding. The content is summarized as follows:
| 1 2 3 4 5 6 7 |
<! -- Do not copy this code! Header is not required here --> <Article> <Header> <H1> My best blog post </Header> <! -- Article content --> </Article> |
If your header element only contains one header element, discard the header element. Since the article element ensures that the header will appear in the document summary, and the header cannot contain multiple elements (as defined above), why do we need to write redundant code. Simply write it like this:
| 1 2 3 4 |
<Article> <H1> My best blog post <! -- Article content --> </Article> |
On the topic headers, I often see the incorrect use of hgroup. Sometimes hgroup and header should not be used simultaneously:
The first problem is generally as follows:
| 1 2 3 4 5 6 7 |
<! -- Do not copy this code! Hgroup is not required here --> <Header> <Hgroup> <H1> My best blog post </Hgroup> <P> by Rich Clark </p> </Header> |
In this example, remove the hgroup and let the heading go.
| 1 2 3 4 |
<Header> <H1> My best blog post <P> by Rich Clark </p> </Header> |
The second problem is another unnecessary example:
| 1 2 3 4 5 6 7 |
<! -- Do not copy this code! Header is not required here --> <Header> <Hgroup> <H1> My company <H2> Established 1893 </Hgroup> </Header> |
If the unique sub-element of the header is hgroup, what about the header? If the header does not contain other elements (such as multiple hgroups), remove the header directly.
| 1 2 3 4 |
<Hgroup> <H1> My company <H2> Established 1893 </Hgroup> |
For more examples and explanations of 3. Do not put all protocol links in nav.
With HTML5 introducing 30 new elements (as of the time of release of the original article), our selection of semantic and structured tags has become somewhat less cautious. That is to say, we should not abuse the hyper-semantic elements. Unfortunately, nav is an example of abuse. The specification of the nav element is described as follows:
The nav element indicates the blocks on the page that are linked to other pages or other parts of the page. It contains the blocks connected by navigation.
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 service terms, home pages, and copyright notice pages. The footer element itself is sufficient to cope with these situations. Although the nav element can also be used here, it is generally considered unnecessary.
Whatwg html spec
The key word is"Main"Navigation. Of course, we can spray each other for a whole day ". I personally define it as follows:
Since there is no absolute right or wrong, according to an informal vote and my own explanation, no matter whether you put it or not, I amNoIn <nav>:
If you are not sure whether 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 primary principles:
If the answer to these questions is "no", just bow to <nav> and leave alone.
Iv. Common Errors of figure elementsCorrect use of figure and figcaption is indeed difficult to control. Let's take a look at some common errors,
Not all images are figureIn the previous article, I told you not to write unnecessary code. The same is true for this error. I have seen many websites write all the images in figure. Do not add additional labels to the image. You just make yourself hurt, but not make your page content clearer.
In the specification, the figure is described as "Some flowing content, sometimes containing its own title description. It is generally referenced as an independent unit in the Document Stream ." This is exactly the beauty of figure-it can be moved from the main content page to the sidebar without affecting the Document Stream.
These issues are also included in the HTML5 element flowchart mentioned earlier.
If the image is purely for rendering purposes and is not referenced elsewhere in the document, it is definitely not <figure>. Others depend on the situation, but at first you can ask yourself: "must this image be related to the context ?" If not, it may not be <figure> (maybe a <aside> ). Continue: "Can I move it to the appendix ?" If both problems match, it may be <figure>. The Logo is not figureFurther, the logo does not apply to figure. Below are some common code snippets:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<! -- Do not copy this code! This is wrong --> <Header> <H1> <Figure> </Figure> My company name </H1> </Header> <! -- Do not copy this code! This is also wrong --> <Header> <Figure> </Figure> </Header> |
There's nothing to say. This is a common error. We can try to determine whether the logo should be an H1 tag, but this is not the focus of our discussion. The real problem lies in the misuse of the figure element. Figure should only be referenced in the document or surrounded by section elements. I think your logo is not very likely to be referenced in this way. Simple. Do not use figure. You only need to do this:
| 1 2 3 4 |
<Header> <H1> My company name <! -- More stuff in here --> </Header> |
Another common misunderstanding about figure is that it is only used by images. Figure can be a video, audio, a chart, a reference text, a table, a piece of code, a piece of prose, and any combination of them or others. Do not limit figure to images. Web standards precisely describe content using tags.
5. Do not use unnecessary type attributesThis is a common problem, but it is not a mistake. I think we should avoid this style through best practices.
In HTML5, the type attribute is no longer required for script and style elements. However, these are likely to be automatically added by your CMS, so removing them is not that easy. However, if you are manually coding or you have full control over your template, there is no reason to include the type attribute. All browsers think that scripts are javascript and styles are css. You don't have to do this any more.
| 1 2 3 |
<! -- Do not copy this code! It is too redundant! --> <Link type = "text/css" rel = "stylesheet" href = "css/styles.css"/> <Script type = "text/javascript" src = "js/scripts"/> |
In fact, you only need to write as follows:
| 1 2 |
<Link rel = "stylesheet" href = "css/styles.css"/> <Script src = "js/scripts"/> |
Even the code of the specified character set can be omitted. Mark PilgrimDive into HTML5In the semantic chapter.
6. incorrect use of form attributesHTML5 introduces some new form attributes. The following are precautions for use:
Boolean attributeSome multimedia elements and other elements also have a Boolean attribute. The rules mentioned here also apply.
Some new form attributes are Boolean, which means that as long as they appear in the tag, the corresponding behavior has been set. These attributes include:
Frankly speaking, I seldom see this. Taking required as an example, the following is common:
| 1 2 3 4 |
<! -- Do not copy this code! This is wrong! --> <Input type = "email" name = "email" required = "true"/> <! -- Another error example --> <Input type = "email" name = "email" required = "1"/> |
Strictly speaking, this is not a serious problem. As long as the browser's HTML Parser sees that the required attribute appears in the tag, its function will be applied. But what if you write equired = "false" in turn?
| 1 2 |
<! -- Do not copy this code! This is wrong! --> <Input type = "email" name = "email" required = "false"/> |
The parser will still regard the required attribute as valid and execute the corresponding behavior, even though you try to tell it not to execute it. This is obviously not what you want.
There are three effective ways to use the Boolean attribute. (The last two types are only valid in xthml)
The correct example is as follows:
| 1 | <Input type = "email" name = "email" required/> |
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
