Geekly Articles each Day
📜 ⬆️ ⬇️

Avoid common HTML5 markup errors.

HTML5 Dear habrovchane, I present you a free translation of the article Avoiding common HTML5 mistakes . Here we look at common mistakes in HTML5 markup in terms of semantics, and how to avoid them.

Watching the sites in the gallery of HTML5 sites and answering user questions, I saw a lot of sites with HTML5 markup. In this article, I will show some of the mistakes and bad markup practices that I often met, and explain how to avoid them.

Do not use the <section> tag as a wrapper for decoration.


One of the most common problems I have noticed is the banal replacement of <div> 's with HTML5 structural elements, especially with <section>' s. Those. when what in xhtml or html looks like this:
<!--    HTML 4 --> <div id="wrapper"> <div id="header"> <h1>My super duper page</h1> <!--   --> </div> <div id="main"> <!--   --> </div> <div id="secondary"> <!--   --> </div> <div id="footer"> <!--   --> </div> </div>
Rewrite as follows:
 <!--    !  ! --> <section id="wrapper"> <header> <h1>My super duper page</h1> <!--   --> </header> <section id="main"> <!--   --> </section> <section id="secondary"> <!--   --> </section> <footer> <!--   --> </footer> </section>

This is simply wrong: <section> is not a wrapper. This element means the semantic block of your content used to build the “document structure” ( document outline ), and should contain a title. If you need an element for a wrapper, try to get by <body> (Kroc Camen has something to offer). If this does not solve the problem of the need for additional wrappers, use the good old <div> 's. With the advent of HTML5, <div> 's have not died , and it is they who are great in this case.

Considering the above, it would be good to mark the example above using HTML5 like this:
 <body> <header> <h1>My super duper page</h1> <!--   --> </header> <div role="main"> <!--   --> </div> <aside role="complementary"> <!--   --> </aside> <footer> <!--   --> </footer> </body>

')
If you are not sure which element to use, then I advise you to use our element selection block diagram (for example, the translator: see the very bottom of the entry ).

Use <header> and <hgroup> only when necessary.


It makes no sense to write code if it is not necessary, right? Alas, but I often observe how <header> and <hgroup> where they are not needed. You can read more about the <header> and <hgroup> elements , but I’ll briefly outline the key points:


Excess <header> elements

I am sure you are well aware that the <header> element can be used several times in a document. Therefore, it is often found this:
 <!--    !  header  ! --> <article> <header> <h1>My best blog post</h1> </header> <!--   --> </article>


If your <header> contains only one header element, then it is not needed. In this case, the <article> element already guarantees that the title will be included in the “document structure” (document outline), and since <header> does not contain several elements (as defined), it can be safely removed. Just enough of this:
 <article> <h1>My best blog post</h1> <!--   --> </article>


Incorrect use of <hgroup>

And again about the headlines: I often see incorrect use of the <hgroup> element. Do not use <hgroup> with <header> if:

The first case:
 <!--    !  hgroup   --> <header> <hgroup> <h1>My best blog post</h1> </hgroup> <p>by Rich Clark</p> </header>


In this case, simply remove the hgroup.
 <header> <h1>My best blog post</h1> <p>by Rich Clark</p> </header>


The second case is another example of using an item unnecessarily.
 <!--    !  header   --> <header> <hgroup> <h1>My company</h1> <h2>Established 1893</h2> </hgroup> </header>


If the only child is <header> 'and it is <hgroup>, why do you need a <header>? If you have no additional elements in <header> 'e (i.e. sister in relation to <hgroup>), just remove <header>.
 <hgroup> <h1>My company</h1> <h2>Established 1893</h2> </hgroup>


Read more about the <hgroup> element here .

Do not frame all links in <nav>


In HTML5, 30 new elements were introduced to enable us to create structured and meaningful markup. But one should not abuse the new semantic elements. Unfortunately, this is exactly what happens with <nav>. The specification describes <nav> like this:

The nav element represents a section of a page linking it to other pages or parts of the current (section with navigation links).

Note: Not all link groups should be placed in the nav element. It should be used for basic navigation . Often in the footers post a small list of links to various pages of the site (Home, Help, agreement on the use, etc ). In this case, one footer should be enough. Although nothing prevents the use of nav, it is not necessary.
WHATWG HTML spec

The key phrase is “main navigation”. One can argue about what is meant by the main one, but for me it is:

Although in this case it is difficult to judge what is right and what is not, I believe that you should not conclude in <nav>:

If you are not sure whether to frame the list of links in <nav>, ask yourself the question: “Is this the main navigation?”. Consider the following:
If the answer to these questions is “No”, this is apparently not the place for <nav>.

Common mistakes in using the <figure> element


Ah, <figure>. Dealing with the correct use of this element, like his colleague <figcaption>, is not easy. Let's take a look at some common errors regarding this element.

Not every image <figure>

Earlier, I advised not to write more code than necessary. Here is a similar situation. I met sites where each picture was framed in a <figure>. No need to use more markup just to use more markup. You simply create more work for yourself, but do not improve the description of your content.

The specification describes a <figure> as “stand-alone content, possibly with a title, and usually being an independent element of the flow”. Here it is, the whole beauty <figure> - the element can be safely moved from the main content, for example, in the sidebar.

The above block diagram of the selection of an element will help you to cope with the figure.

If the image carries only the presentation load and is not referenced anywhere in the document, it is definitely not a <figure>. Otherwise, ask yourself the question: “Is this image in the current context necessary for understanding?”. If not, this is apparently not a <figure> (perhaps <aside>). If so, ask yourself, “Can I move this into the app?”. If the answer to both questions is Yes, then perhaps the <figure> will do.

Your logo is not <figure>

The same goes for the logo. Often I see such an application:
 <!--    !  ! --> <header> <h1> <figure> <img src="/img/mylogo.png" alt="My company" class="hide" /> </figure> My company name </h1> </header> 
 <!--    !  ! --> <header> <figure> <img src="/img/mylogo.png" alt="My company" /> </figure> </header>

There is nothing to add. This is simply not true. One can argue for a long time about whether the logo should be in <h1>, but we are not talking about that right now. The real mistake is the abuse of the <figure> element. <figure> should only be used when you refer to it in a document. It is unlikely that you will link to your logo anywhere. Enough of this:
 <header> <h1>My company name</h1> <!--  - --> </header>


<figure> may not be just an image

Another common misunderstanding of the <figure> element is to assume that it can only be used for images. But it is not. A <figure> can contain video, audio, graphics (in SVG, for example), a quote, a table, a block of code, a poem, or any combination of the above. Do not limit yourself to using <figure> images. Our goal as web standards advocates is to describe our markup content.

Not long ago, I wrote about the <figure> element in more detail. I advise you to read if you want to understand better or refresh your memories.

Do not use unnecessary type attribute


This is perhaps the most common problem encountered in the HTML5 gallery. Although it is not a mistake, I think it is better to avoid it.

In HTML5, there is no need to specify the type attribute for the <script> and <style> elements. Although it may not be easy to get rid of them if they are automatically added by your CMS, it makes no sense to include them in the code if you write it yourself or can manage the templates. Because All browsers by default assume that all scripts are written in JavaScript, and styles are CSS, this markup becomes redundant:
 <!--    !   ! --> <link type="text/css" rel="stylesheet" href="css/styles.css" /> <script type="text/javascript" src="js/scripts"></script>

Instead, you can simply write:
 <link rel="stylesheet" href="css/styles.css" /> <script src="js/scripts"></script>


Among other things, you can also reduce the amount of code spent on specifying the encoding. Mark Pilgrim's chapter on semantics in the book Dive into HTML5 describes all such practices.

Incorrect use of form attributes


You must already be aware that many new form attributes have been introduced in HTML5. We will consider them in the near future, but now I will briefly tell you how not to do it.

Boolean attributes

There are logical attributes also for multimedia elements and some others. The rules I describe apply to them.

Some of the new form attributes are logical, i.e. their presence in the markup determines the behavior of the elements. Including this:


I rarely meet them, but in the case of required I saw this:
 <!--    !  ! --> <input type="email" name="email" required="true" /> 
 <!--     --> <input type="email" name="email" required="1" />


Ultimately, it does not threaten anything bad. The client HTML parser will meet the required attribute in the markup and apply the appropriate rules. But what if done differently and write required = "false"?
 <!--    !  ! --> <input type="email" name="email" required="false" />

The parser will still see the required attribute and apply the appropriate behavior, despite the fact that you have instructed it not to do so. Obviously, this is not what you wanted.

The logical value can be applied in three ways: (The second and third are characteristic for XHTML)

With reference to our example above, we could write this (in HTML):
 <input type="email" name="email" required />

Source: https://habr.com/ru/post/124993/

More articles:


All Articles