Front-end: 6 common HTML5 error usages and 6 front-end html5 Usages
I. Do not use section as a substitute for div
One of the most common errors in tag use is to randomly integrate HTML5<section>Equivalent<div>-- Specifically, it is directly used as a substitute (for style ). In XHTML or HTML4, we often see the following code:
<!-- HTML 4-style code --><div id="wrapper"> <div id="header"> But now in HTML5, it will be like this:
Do not copy the code! This is wrong!
<section id="wrapper">
This is incorrect :**
It is not a style container. ** The section element indicates 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)
<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 necessary
Writing 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:
- The header element represents a set of introductory or navigation-oriented secondary texts and is often used as the section header.
- When the header has a multi-layer structure, such as a sub-head, sub-title, a variety of Logo text, etc., use hgroup to combine h1-h6 elements as the section header
Header abuse
Because the header can be used multiple times in a document, the Code style may be welcomed:
Do not copy this code! Header is not required here->
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:
<article>
Incorrect Use
On the topic headers, I often see the incorrect use of hgroup. Sometimes hgroup and header should not be used simultaneously:
- If there is only one Subheader
- If the hgroup itself can work well... Isn't that nonsense?
The first problem is generally as follows:
Do not copy this code! Hgroup->
In this example, remove the hgroup and let the heading go.
The second problem is another unnecessary example:
Do not copy this code! 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.
About
For more examples and explanations, see related articles.
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.
The key word is the "Main" navigation. Of course, we can spray each other for a whole day ". I personally define it as follows:
- Main navigation
- Intra-Site Search
- Second-level navigation (slightly controversial)
- Navigation on the page (for example, a long article)
Since there is no absolute right or error, according to an informal vote and my own explanation, no matter whether you put it or not, I will not put it in it:
- Paging Control
- Social links (although some social links are also the main navigation, such as "about" favorites ")
- Blog Post tag
- Blog articles
- Third-level navigation
Too long footer
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 you use section and hx, do not use nav-Hixie on IRC.
To facilitate access, will you add a link to this nav tag in a "quick jump?
- If the answer to these questions is "no", just bow and leave alone.
Iv. Common Errors of figure elements
Correct use of figure and figcaption is indeed difficult to control. Let's take a look at some common errors,
Not all images are figure
In 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
. 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 (maybe ). Continue: "Can I move it to the appendix ?" If both problems match, it may be.
The Logo is not figure
Further, the logo does not apply to figure. Below are some common code snippets:
<! -- Do not copy this code! This is incorrect -->
<! -- Do not copy this code! This is also incorrect -->
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:
Figure is not just an image
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 attributes
This 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.
<! -- 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 "/> </script>
In fact, you only need to write as follows:
<link rel="stylesheet" href="css/styles.css" /><script src="js/scripts" /></script>
Even the code of the specified character set can be omitted. Mark Pilgrim explained in the semantic chapter of Dive into HTML5.
6. incorrect use of form attributes
HTML5 introduces some new form attributes. The following are precautions for use:
Boolean attribute
Some 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:
- Autofocus
- Autocomplete
- Required
Frankly speaking, I seldom see this. Taking required as an example, the following is common:
<! -- 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?
<! -- 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)
- Required
- Required = ""
- Required = "required"
The correct example is as follows:
<Input type = "email" name = "email" required/>
[I have a QQ Group for front-end learning and communication: 328058344 if you encounter any problems during the process of learning the front-end, please come to my QQ Group to ask questions. The group will update some learning resources every day. Chat is prohibited .]
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
