Front-end: 6 common HTML5 misuses

Front-end: 6 common HTML5 misuses

1. Don’t use section as a replacement for div

One of the most common mistakes people make when using tags is to arbitrarily equate HTML5's <section> to <div> - specifically, to use it as a direct replacement (for styling). In XHTML or HTML4, we often see code like this:

  1.  <! -- HTML 4-style code --><div id="wrapper">  
  2.  <div id= "header" >
  3.         <h1>My super duper page</h1>
  4.         Header content </div>
  5.  <div id= "main" >
  6.         Page content </div>
  7.  <div id= "secondary" >
  8.         Secondary content </div>
  9.  <div id= "footer" >
  10.         Footer content </div></div>

Now in HTML5, it will look like this:

Please do not copy this code! It is wrong!

  1.  < section id = "wrapper" >
  2.  <header>
  3.         <h1>My super duper page</h1>
  4.         <! -- Header content -->  
  5.  </header>
  6.  < section id = "main" >
  7.         <! -- Page content -->  
  8.  </ section >
  9.     < section id= "secondary" >
  10.         <! -- Secondary content -->  
  11.  </ section >
  12.  <footer>
  13.         <! -- Footer content -->  
  14.  </footer> </section>

This is incorrect: it is not a style container. The section element represents a semantic section of content that helps build the outline of the document. It should contain a header. If you are looking for an element that acts as a page container (in the style of HTML or XHTML), then consider writing styles 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 is an example of the correct use of HTML5 and some ARIA roles features (note that depending on your own design, you may also need to add divs)

  1.  <body><header>
  2.     <h1>My super duper page</h1>
  3.     <! -- Header content --></header><div role="main">  
  4.     <! -- Page content --></div><aside role="complementary">  
  5.     <! -- Secondary content --></aside><footer>  
  6.     <! -- Footer content --></footer></body>  

If you are still unsure which element to use, I recommend referring to the HTML5 sectioning content element flowchart.

2. Use header and hgroup only when needed

It is pointless to write tags that are not needed. Unfortunately, I often see header and hgroup elements being misused. You can read two articles about header and hgroup elements for a detailed understanding, but I will briefly summarize the content as follows:

  • The header element represents a set of introductory or navigational text and is often used as a section header.
  • When the header has multiple layers, such as sub-headers, subtitles, and various logo texts, use hgroup to combine h1-h6 elements as the section header.

Abuse of headers

Since headers can be used multiple times in a document, this coding style may be popular:

Please do not copy this code! The header is not needed here –>

  1.  <header>
  2.         <h1>My best blog post</h1>
  3.  </header>
  4.     <! -- Article content --></article>  

If your header element only contains one header element, then 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:

  1.  <article>
  2.     <h1>My best blog post</h1>
  3.     <! -- Article content --></article>  

Incorrect use of

On the topic of headers, I also often see the incorrect use of hgroup. Sometimes you shouldn't use hgroup and header together:

  • If there is only one subheader
  • If hgroups work just fine on their own... Isn't that nonsense?

The first question usually goes something like this:

Please do not copy this code! hgroup is not needed here –>

  1.  <hgroup>
  2.         <h1>My best blog post</h1>
  3.  </hgroup>
  4.     <p> by Rich Clark</p></header>

In this case, just remove the hgroup and let the heading run as is.

  1.  <header>
  2.     <h1>My best blog post</h1>
  3.     <p> by Rich Clark</p></header>

The second question is another example of something unnecessary:

Please do not copy this code! No header is needed here –>

  1.  <hgroup>
  2.  <h1>My company</h1>
  3.         <h2>Established 1893</h2>
  4.  </hgroup></header>

If the only child element of the header is hgroup, what is the point of the header? If there are no other elements in the header (such as multiple hgroups), just remove the header. (Web front-end learning exchange group: 328058344 No idle chat, no entry if you don't like it!)

  1.  <hgroup>
  2.  <h1>My company</h1>
  3.     <h2>Established 1893</h2></hgroup>

For more examples and explanations, see the related article

3. Don’t put all list links in nav

With HTML5 introducing 30 new elements (at the time of this post), our choices in constructing semantic and structural markup have become somewhat imprudent. That is, we should not abuse hyper-semantic elements. Unfortunately, nav is an example of such abuse. The specification of the nav element describes it as follows:

The nav element represents a block in the page that links to other pages or other parts of the page; a block that contains navigation links.

Note: Not all links on a 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 the footer, such as the terms of service, home page, copyright notice page, etc. The footer element itself is sufficient for these situations, and although the nav element can also be used here, it is generally considered unnecessary.

The key word is "primary" navigation. Of course, we can argue all day about what "primary" means. Here's how I define it:

  • Main navigation
  • Search the site
  • Secondary navigation (slightly controversial)
  • Navigation within a page (e.g. a long article)

Since there is no absolute right or wrong, based on an informal vote and my own interpretation, I will not put the following in your opinion, regardless of whether you put it in or not.

middle:

Paging Control

Social links (although some social links are also primary navigation, such as "About" and "Favorites")

  • Tags for blog posts
  • Blog post categories
  • Three-level navigation
  • Too long footer

If you’re unsure whether to place a series of links in a nav, ask yourself: “Is it the primary navigation?” To help you answer this question, consider these first principles:

Don't use nav if section and hx are equally appropriate — Hixie on IRC

  • For easy access, would you add a link to this nav tag in a "quick jump"?

If the answer to these questions is "no", then follow

  • Bow and leave alone.

IV. Common mistakes with figure elements

The correct use of figures and figcaptions can be difficult to master. Let's look at some common mistakes.

Not all images are figures.

Earlier, I told you not to write unnecessary code. This mistake is the same. I see a lot of websites that label all images as figure. Please don't add extra tags for the sake of the image. You're just annoying yourself and not making your page clearer.

The specification describes a figure as "a piece of flowing content, sometimes with its own caption. It is generally referenced as a separate unit in the document flow." This is the beauty of a figure - it can be moved from the main content page to the sidebar without affecting the document flow.

These issues are also covered in the HTML5 element flowchart mentioned earlier.

If the figure is purely for presentation and is not referenced elsewhere in the document, then it is definitely not. The rest depends, but a good place to start is to ask yourself: "Does this figure have to be relevant to the context?" If not, then it's probably not (maybe it is). Follow up with: "Can I move it to an appendix?" If both questions are true, then it probably is.

A logo is not a figure

Furthermore, logo is not suitable for figure. Here are some common code snippets I use:

  1.  <! -- Please do not copy this code! It is wrong --><header>  
  2.  <h1>
  3.         <figure> ![My company](/img/mylogo.png) </figure>
  4.         My company name </h1></header> 
  5.  
  6.  <! -- Please do not copy this code! This is also wrong --><header>  
  7.     <figure> ![My company](/img/mylogo.png) </figure></header>

There's not much else to say. This is a very common mistake. We can argue over whether a logo should be an H1 tag or not, but that's not the point. The real problem is the misuse of the figure element. Figures should only be referenced within a document, or surrounded by section elements. I don't think your logo is referenced in this way. Simple, don't use a figure. You just need to do this:

  1.  <header>
  2.  <h1>My company name </h1>
  3.     <! -- More stuff in here --></header>  

Figure is not just a picture

Another common misconception about figures is that they are only used for images. Figures can be video, audio, a chart, a quote, a table, a piece of code, a piece of prose, or any combination of these or others. Don't limit figures to images. It is the job of web standards to accurately describe content with tags.

5. Don’t use unnecessary type attributes

This is a common problem, but it is not a mistake, and I think we should avoid this style through best practices.

In HTML5, script and style elements no longer require type attributes. However, these are likely to be added automatically by your CMS, so it is not easy to remove them. But if you are hand-coding or you have full control over your templates, there is really no reason to include type attributes. All browsers assume that scripts are javascript and styles are CSS styles, so there is no need to do this.

  1.  <! -- 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, you only need to write:

  1.  <link rel= "stylesheet" href= "css/styles.css" /><script src= "js/scripts" /></script>

Even the code that specifies the character set can be omitted, as Mark Pilgrim explains in the Semantics chapter of Dive into HTML5.

6. Incorrect use of form attributes

HTML5 introduces some new form attributes. Here are some notes on their use:

Boolean properties

Some multimedia elements and other elements also have Boolean attributes. The same rules apply here.

Some of the new form attributes are boolean, meaning that their presence in the markup ensures that the corresponding behavior is set. These attributes include:

  • autofocus
  • autocomplete
  • required

Frankly speaking, I rarely see this. Taking required as an example, the following is common:

  1.  <! -- Please do not copy this code! It is wrong! --><input type="email" name="email" required="true" /><!--  
  1.  Another incorrect example - <input type="email" name="email" required="1" />  

Strictly speaking, this is fine. As long as the browser's HTML parser sees the required attribute appear in the tag, its functionality will be applied. But what if you write required="false" in reverse?

  1.  <! -- Please do not copy this code! It 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. This is obviously not what you want.

There are three valid ways to use Boolean attributes. (The last two are only valid in XTHML)

  • required
  • required=””
  • required=”required”

The correct way to write the above example should be:

  1.  <input type= "email"   name = "email" required />

<<:  How to compile iOS projects 5 times faster

>>:  Serialize the Intent and pass it like a Uri!!!

Recommend

5 interactive principles you need to master for event operations!

This article combines nearly a hundred case studi...

Changsha tea tasting service, tea takeaway studio, high-end audition recommended here

185-6916-1745 Micro.Q Synchronization The masseus...

What is the approximate price of customized mini programs purchased online? What factors are related to the price of customized mini programs in Foshan?

In order to ensure that the developed mini progra...

Haval's sales have dropped sharply, while the new brand WEY started strong but ended weak. Where is the turning point for Great Wall Motors?

Great Wall Motors' recent sales are not optim...

108 Internet Marketing Tools/Websites

Ever since the Wei Zexi incident broke out last y...

Danger! An owner knocked down this wall, causing the entire house to become a dangerous building! You must know these when renovating...

Expert: Dr. Xie Qiang, Geotechnical Engineer, Off...

Pinduoduo Operations: What tricks does Pinduoduo use to get things for free through bargaining?

The bargaining and free-getting activities that h...

Tmall responds to the fake number of reservations for Hammer smartphones: It was done by programmers

On October 12, Tmall, one of the online sales cha...

What is Haosheng APP? Is it reliable? How to make money?

1. What is a good province? Answer: Haosheng is a...

Corolla's monthly sales of 2,268 units lead Taiwan Province. If mainland cars enter Taiwan, how will the market change?

In recent days, Taiwan has been a very hot word, ...

Jack Ma's automotive ambition: buying, selling, washing and repairing cars

Everyone knows that BAT is eyeing the automotive ...

How to create a new brand from 0 to 1?

The scientific spirit can help us find relative c...

3 concepts for practical data analysis and decision-making!

The new graduates have a good understanding of th...

Operation and promotion plan after the event goes online!

First look at this picture: I divided the operati...

Taking Meituan Takeaway’s personal report as an example, let’s talk about user personal behavior reports!

We try to reflect the value of our product throug...