One of the most common mistakes people make when using tags is to equate HTML5's <section> with <div> - specifically, using it directly as a replacement (for styling purposes). In XHTML or HTML4, we often see code like this:
<!-- HTML 4-style code --><div id=wrapper> <div id=header> <h1>My super duper page</h1> Header content </div> <div id=main> Page content < /div> <div id=secondary> Secondary content </div> <div id=footer> Footer content </div></div>
Now in HTML5, it will look like this:
Please do not copy this code! This is wrong!
<section id=wrapper> <header> <h1>My super duper page</h1> <!-- Header content --> </header> <section id=main> <!-- Page content --> </ section> <section id=secondary> <!-- Secondary content --> </section> <footer> <!-- Footer content --> </footer></section>
This usage is incorrect:**
It is not a style container. The **section element represents the semantic part of the content used to help build a document summary. It should contain a header. If you're looking for an element that acts as a page container (like HTML or XHTML style), then consider writing the style directly to the body element, as Kroc Camen suggests. If you still need additional style containers, stick with divs.
Based on the above ideas, the following are examples of correct use of HTML5 and some ARIA roles features (note that depending on your own design, you may also need to add divs)
<body><header> <h1>My super duper page</h1> <!-- Header content --></header><div role=main> <!-- Page content --></div>< aside role=complementary> <!-- Secondary content --></aside><footer> <!-- Footer content --></footer></body>2. Use headers and hgroups only when needed
There is of course no point in writing labels that don't need to be written. Unfortunately, I often see headers and hgroups misused for no purpose. You can read the two articles about header and hgroup elements for a detailed understanding. I briefly summarize the contents as follows:
Since headers can be used multiple times in a document, this may make this coding style popular:
Please do not copy this code! No header is needed here –>
<header> <h1>My best blog post</h1> </header> <!-- Article content --></article>
If your header element contains only one header element, discard the header element. Since the article element already guarantees that the header will appear in the document summary, and the header cannot contain multiple elements (as defined above), why write extra code. Simply write it like this:
<article> <h1>My best blog post</h1> <!-- Article content --></article>
incorrect use of
On the topic of headers, I also often see hgroups being used incorrectly. Sometimes hgroup and header should not be used together:
The first question usually looks like this:
Please do not copy this code! No hgroup is needed here –> <hgroup> <h1>My best blog post</h1> </hgroup> <p>by Rich Clark</p></header>
In this example, just remove the hgroup and let the heading run its course.
<header> <h1>My best blog post</h1> <p>by Rich Clark</p></header>
The second question is another unnecessary example:
Please do not copy this code! No header is required here –>
<hgroup> <h1>My company</h1> <h2>Established 1893</h2> </hgroup></header>
If the only sub-element of the header is hgroup, what else does the header do? If there are no other elements in the header (such as multiple hgroups), just remove the header directly.
<hgroup> <h1>My company</h1> <h2>Established 1893</h2></hgroup>3. Don’t put all list-like links in nav
With the introduction of 30 new elements in HTML5 (as of the time of the original publication), our choices in constructing semantic and structured tags have become somewhat careless. That said, we shouldn't abuse hyper-semantic elements. Unfortunately, nav is an example of such an abuse. The specification for the nav element is described as follows:
The nav element represents a block in the page that links to other pages or other parts of this page; a block that contains navigation connections.
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. To give a specific example, there are often many links in the footer, such as terms of service, homepage, copyright statement page, etc. The footer element itself is sufficient to handle these situations. Although the nav element can also be used here, we usually think it is unnecessary.
Key words are primary navigation. Of course we can squirt each other all day long about what's important. This is how I define it personally:
For easier access, will you add a link to this nav tag in a shortcut jump?
If the answer to these questions is no, just take a bow and go off on your own.
4. Common mistakes in figure elementsThe correct use of figure and figcaption is indeed difficult to master. Let’s take a look at some common mistakes,
Not all pictures are figures
Above, I told you not to write unnecessary code. The same goes for this error. I've seen many websites label all pictures as figures. For the sake of the picture, please don't add extra tags to it. You're just hurting yourself and not making your page any clearer.
Figures are described in the specification as flowing content, sometimes with their own title description. Generally, they are referenced as independent units in the document flow. This is the beauty of the figure - it can be moved from the main content page to the sidebar without affecting the document flow.
These issues are also covered by the HTML5 element flowchart mentioned earlier.
If the diagram is purely for presentation and is not referenced elsewhere in the document, then it is definitely not
. The rest depends on the situation, but start by asking yourself: Does this image have to be relevant to the context? If not, it probably isn't either (maybe it is). Moving on: Can I move this to an appendix? If both questions apply, it probably is.
Logo is not a figure
Furthermore, logos do not apply to figures either. Here are some common code snippets I use:
<!-- Please do not copy this code! This is wrong--><header> <h1> <figure> ![My company](/img/mylogo.png) </figure> My company name </h1 ></header><!-- Please do not copy this code! This is also wrong--><header> <figure> ![My company](/img/mylogo.png) </figure></header>
There is nothing more to say. This is a very common mistake. We can argue with each other until the cows go home over whether the logo should be an H1 tag, but that’s not the point here. The real problem is the overuse of the figure element. Figures should only be referenced within the document, or surrounded by section elements. I think it is unlikely that your logo will be referenced in this way. It's simple, don't use figure. You just need to do this:
<header> <h1>My company name</h1> <!-- More stuff in here --></header>
Figure is not just a picture
Another common misconception about figure is that it is only used by pictures. A figure can be a video, audio, chart, quotation, table, code, prose, or any combination of these or others. Don't limit figures to pictures. It is the job of web standards to accurately describe content using tags.
5. Do not use unnecessary type attributesThis is a common problem, but not a mistake, and I think we should avoid this style through best practices.
In HTML5, script and style elements no longer require the type attribute. However, these are likely to be automatically added by your CMS, so it is not so easy to remove them. But if you're coding by hand or you have complete control over your templates, there's really no reason to include the type attribute. All browsers think that scripts are javascript and styles are css styles, so you don't need to do this anymore.
<!-- Please 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, all you need to do is write:
<link rel=stylesheet href=css/styles.css /><script src=js/scripts /></script>
Even the code specifying the character set can be omitted. Mark Pilgrim explains it in the Semantics chapter of Dive into HTML5.
6. Incorrect use of form attributeHTML5 introduces some new attributes of form. Here are some notes on usage:
Boolean properties
Some multimedia elements and other elements also have Boolean properties. The same rules apply here.
Some of the new form attributes are boolean, which means that as long as they appear in the label, the corresponding behavior is guaranteed to be set. These properties include:
Frankly, I rarely see this. Taking required as an example, the common ones are as follows:
<!-- Please do not copy this code! This is wrong! --><input type=email name=email required=true /><!-- Another example of a mistake --><input type=email name =email required=1 />
Strictly speaking, this is no big deal. As long as the browser's HTML parser sees the required attribute appearing in a tag, its functionality will be applied. But what if you write required=false the other way around?
<!-- Please do not copy this code! This is wrong! --><input type=email name=email required=false />
The parser will still treat the required attribute as valid and perform the corresponding behavior, even if you try to tell it not to perform it. This is obviously not what you want.
There are three valid ways to use Boolean properties. (The latter two are only valid in xthml)
The correct way to write the above example is:
<input type=email name=email required />Summarize
The above is what the editor introduces to you on how to avoid 6 common incorrect usages of HTML5. I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. I would also like to thank everyone for your support of the VeVb martial arts website!