8 HTML Elements You’re Not Using (and Should Be)

In today's web, the word semantic gets thrown around a lot. But what does semantic mean? Why is it important?

Semantic HTML expresses the meaning of the document. It's less about how the text looks and more about what it is. Good semantic markup helps both people and machines understand the content and its context.

Semantic markup is much more accessible and easier for screen readers to interpret. It's SEO friendly. It works better with modern browsers. It reduces the amount of code needed to express the content and increases the clarity of the code for other people that have to read it.

Okay, so semantic content is great, but how do you use it? One of the best ways to start writing better markup is to replace generic tags with more expressive elements. Let's take a look at eight that you can use to step up your game.

<q>

Like it's blockier cousin <blockquote>, the <q> tag is used for quoted text.

Why not just use quotation marks? Quotation marks don't always imply a quote. Sometimes they're used for emphasis, irony, or to identify the name of something. In those cases, using quotation marks directly in the content is perfectly valid. However, if you're quoting someone, <q> explicitly shows your meaning.

<i> and <b>

Back in the good old days, <i> and <b> were used to identify italic and bold text. When the idea of separating semantic content from presentation started to gain traction, using <i> and <b> became frowned upon because they represented how the text was displayed, instead of what it meant. They were replaced by <em> and <strong>, which indicates emphasized and strongly emphasized text.

With HTML5, <i> and <b> now have shiny new semantic meanings. The <i> tag is used for text that is in a separate tone or mood. This is useful for things like thoughts and technical terms. The <b> tag identifies text that is stylistically different than normal text, but doesn't have any semantically different meaning. How is this different than using <span>? The key is that <b> communicates a lack of semantic meaning.

<abbr>

<abbr>'s are used for abbreviations! This can be really handy in documents with several short abbreviations. <abbr>'s have an optional title attribute that contains the unabbreviated version of the text.

<time>

Let's take a look at a classic localization problem: dates. In the United States, October 5th, 2013 is represented by 10/05/13. In the United Kingdom, it's 05/10/13. In the Netherlands, October 5th would be written 05-10-13; in South Africa it would be 2013/10/05 and in Russia it's 05.10.13. With all of these possibilities, it's difficult for a machine to correctly read dates in all of these locales.

The <time> tag allows you to represent time and dates in a machine-readable format. The above example could be written as <time datetime="2013-10-05">10/05/13</time>. A HTML parser can use this to determine the exact time we meant, regardless of how it is formatted. The <time> tag also allows an optional 24-hour formatted time to be appended to the date: <time datetime="2013-10-05 22:00">10/05/13 at 10 PM</time>;

<mark>

Ever do something like this?

<p>
Three hundred pages of boring, useless text. <span class="highlight">The one thing you need to know and will never be able to find again if you don't highlight it.</span> More boring stuff…
</p>

Well, now you don't need to. HTML5 introduced the <mark> element, which represents highlighted text that is, text that's marked for referential purposes due to its relevance in another context.

<input>

Yes, <input>. You've probably used <input type="text">, <input type="submit"> and maybe even <input type="hidden"> at some point, but have you used any of the other types? With HTML5, <input>'s can now be used with a range of types, including:

email

tel

number

range

date

time

search

color

These are great, but make sure they meet your browser requirements before you use them. Some types still aren't supported by all major browsers.

Bonus

Most front end developers have used &nbsp; when writing HTML, but many don't know the real meaning of the character. A non-breaking space will not break on a new line. This means that if you have two words separated by a non-breaking space, then both words will stick together at the end of a sentence. This is handy when breaking the words might be disruptive. Some great examples are:

Units: 12 m/s

Time: 8 PM

Proper nouns: Dairy Queen

Also, be sure to check out the non-breaking hyphen (&#8209;), which lets you use a hyphen character that won't break.

About Landon Schropp

Landon is a developer and entrepreneur based in Seattle. He's the author of the Free Flexbox Starter Course and Unraveling Flexbox, a book on how to create modern, responsive layouts in CSS. He's passionate about building simple apps people love to use.

The <canvas> element has been a revelation for the visual experts among our ranks. Canvas provides the means for incredible and efficient animations with the added bonus of no Flash; these developers can flash their awesome JavaScript skills instead. Here are nine unbelievable canvas demos that...

You've probably heard the talk around the water cooler about how promises are the future. All of the cool kids are using them, but you don't see what makes them so special. Can't you just use a callback? What's the big deal? In this article, we'll...

Spatial navigation is the ability to navigate to focusable elements based on their position in a given space. Spatial navigation is a must when your site or app must respond to arrow keys, a perfect example being a television with directional pad remote. Firefox OS TV apps are simply...

Discussion

I’ve been looking into some of these recently. A good take away I got from reading the spec on the q element was that quotes around text is just as valid as the q tag. The q element seems to be more for consistent styling of inline quotes. And optionally to remove any ambiguities as you highlight in the article.

The use of q elements to mark up quotations is entirely optional; using explicit quotation punctuation without q elements is just as correct.

A menu is not always a navigation.
The “ tag is meant to be used as the navigation of the website, while the “ tag is entirely different. The author posted 2 examples for what a menu can be, context and toolbar.

@Geoffrey The <nav> tag is used for sections of the document that contain navigation links. While it’s true that a <nav> tag can contain a <menu> (and my example would probably be contained within one), not all menus are navigation menus.

I agree the nav element should be used in your example. From W3C (http://www.w3.org/TR/html-markup/nav.html) The nav element represents a section of a document that links to other documents or to parts within the document itself; that is, a section of navigation links.

Where as you state bonus points for specifying toolbar or context menu W3C states that all it should be used for. From W3C (The menu element is used to define context menus and toolbars.) The menu element represents a list of commands.
“toolbar”: Indicates that the element represents a tool bar.
“context”: Indicates that the element represents a context menu.
If the attribute is omitted, the element represents a list of commands that is neither a context menu nor a tool bar.

Pretty poor article. Not only have you missed out a load of input types, but you’ve used the wrong element () for … not only that isn’t implemented!

Also you’re missing out (soon to be) more important semantic elements such as , , , , , , etc.

Ricky Duckworth

Great, now I look like the idiot;

First missing elem – “menu”
Second – “nav”

Remainder:

, , , , , ,

Dan Jones

To suggest that you should use the menu tag is a bit absurd, so no major browser supports it.

Adam

I completely disagree with the italic and bold tags part of this article.

An i-tag indicates something is being rendered as italic… the b-tag indicates something is being rendered as bold. Anything else is massive speculation and should be avoided at ALL COSTS!

If you prefer em or strong that’s fine, go nuts!… but if you just wanted italic or bold text… and 100% support in legacy browsers… I and b tags are your friend. I’d rather save 12 characters of markup/typing any day of the week making text italic or bold with the HTML tags that work flawlessly.

Darcy

Re: . I don’t think it’s something we should be using just yet. Firefox is the only one that supports it and only partially so (ref: http://caniuse.com/#search=menu).

That being said, the coolest place for would be mobile too. Being able to employ native looking navigation on a web-app that would fit in with whichever mobile OS you’re looking at it on will be great if this gets full support someday.

I think that most developers worth their salt are at least somewhat aware of these elements. The biggest challenge I see, especially for those inline semantic elements like abbr and q is that the content on sites we build is entered and managed by CMS users that don’t have that knowledge or appreciation of their semantic value-add. Worse, we’re giving them “WYSIWYGy” tools that help by giving them a familiar word processor interface but doing the disservice of having them think no further than they would on a word processor.

Anyone else have the same concerns? Ideas on how to overcome this? Education? A role of “web editor” that stands between a content writer and the publishing of her content?

The tag caught my attention because I have seen it before and was wondering if it exists. Due to caniuse however it has very poor browser support (14.7%) and it’s not sure if future Chrome version are gonna implement it. Do you have any further insights on that?

Apart from that, great article. I always appreciate people pushing forward good semantics!

Felipe Diogo

I don’t get why people are criticizing so hard…

You know instead of saying “sugesting is absurd”

Can’t you just say “Man, “” is not supported in major browsers”

He put effort to make an article to spread knowledge. Don’t be a jerk.

How ironically is it that the W3C HTML5.0 spec, referenced at the end of the article, currently… doesn’t contain menu element at all! Only the draft of the upcoming revision of W3C HTML5 spec, HTML5.1, and WHATWG HTML Living Standard contain it.

Also, W3C HTML validator gives a following warning: “The menu element is not supported by browsers yet. It would probably be better to wait for implementations”.

I love using tags to semantically style simple abbreviations. Just wrap an abbreviation with the tag, give it a font-size of 90% or 95% and a letter-spacing of 1px, and behold—quick and beautiful typography that relatively easy to author.

Continue this conversation via emailGet only replies to your comment, the best of the rest, as well as a daily recap of all comments on this post. No more than a few emails daily, which you can reply to/unsubscribe from directly from your inbox.