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

On World Pangolin Day, can we wait for good news about pangolins?

Today - the third Saturday in February - is World...

Qiu Yuan's Victoria's Secret Body Shaping Private Tutoring Video 14 Lessons

Qiu Yuan's Victoria's Secret Body Shaping...

Give you a complete set of community operation solutions

The value of WeChat groups, QQ groups, and Zhangh...

10 marketing misunderstandings and 10 opportunities in 2020 (Part 2)

For marketing, 2020 was a year of challenges, but...

Is “radon health care” “health care” or “playing with life”?

In recent years, "radon health care" ha...

How to become a master of study Peking University will help you improve your study efficiency 10 times

How to become a master of study Peking University...

OPPO R9 from the perspective of its frame: An Android phone reshaping the iPhone

In an era of highly homogenized smartphone hardwa...

Activity promotion: Let’s talk about how to draw lucky draws to attract new customers

The event lottery mini program is probably no str...

Concrete operations: basic operation skills and common tools!

I often hear Internet professionals say: "Pro...

"I'm afraid my father will be gone!" The young man's decision brought tears to the eyes of many netizens...

recent Bai Junlong, a young man from Xichang, Sic...

When did the “windows of the soul” become “frosted glass”?

Audit expert: Peng Guoqiu Deputy Chief Physician,...

Electric Technology Car News: As a once leading model but now in decline, Tiguan L can still crush its rivals with its performance and space

Tiguan, once the leading model of joint venture S...

WWDC 2016 Wishlist for iOS Developers

[[164900]] I don't usually write articles lik...

Comprehensive insight into explosive user growth!

Fission growth? AARRR model? These familiar conce...

Programmatic Advertising Quantitative Evaluation Revenue Indicator - eCPM

This article will share with you how to improve &...