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.
<abbr title="laugh out loud">lol</abbr> <abbr title="I don't know">idk</abbr> <abbr title="got to go">g2g</abbr> <abbr title="talk to you later">ttyl</abbr>
<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:
emailtelnumberrangedatetimesearchcolor
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.
<menu>
Have you ever marked up a menu with an unordered list?
<ul class="menu-toolbar"> <li class="new">New</li> <li class="open">Open</li> <li class="save">Save</li> <li class="quit">Quit</li> </ul>
Well stop! menu is designed for this purpose. The <menu> element represents an unordered list of commands. It has a type attribute, which can be set to popup or toolbar.
<menu type="toolbar"> <li class="new">New</li> <li class="open">Open</li> <li class="save">Save</li> <li class="quit">Quit</li> </menu>
Bonus
Most front end developers have used 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 (‑), which lets you use a hyphen character that won't break.
Wrapping up
HTML is growing more semantic by the day. Using these elements is a great start to writing cleaner, more accessible markup. For a more complete look at all of the available options, check out the Periodic Table of the Elements, the Mozilla Developer Network documentation or, if you're feeling bold, the W3C's HTML specification. Have fun!
About Landon Schropp
Landon is a developer, designer and entrepreneur based in Kansas City. He's the author of the Unraveling Flexbox. He's passionate about building simple apps people love to use.
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.
http://www.w3.org/TR/html5/text-level-semantics.html#the-q-element
Isn’t the nav tag a better option for a main menu on a site? confusing spec.
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.
As Adonis mentioned the navigation tag would contain a menu within it instead of a ul as mentioned in the post.
@Daniel You’re right. Thanks for the clarification. :)
@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.!!
idon’t know !
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-menu-element
is for “list of commands”, not “list of links” or “site navigation” (it’s not ).
You shouldn’t use it for site navigation.
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.
Okay, the <menu> criticism is fair. It looks like the MDN information on that element is a little out of date. I’ll fix that section of the article later.
Thanks for sharing these information’s your tips are really good.
great tips. very well-written, keyword-oriented and incredibly useful.
its really interesting to many readers. I really appreciate this, thanks
Menu tag? It’s only supported in Firefox. You should add browser support specs if you’re recommending something. More knowledge equals better semantic.
You’re right, I should have mentioned browser support. Thanks for pointing it out.
Where does this strange date format in the United States even come from? Nice to see that Africa is outpacing Europe. I think everybody should use the ISO date format.
+1 on that, Matt!
Time is never scrambled – it’s always written h:m:s. Never seen anyone write it m:h:s or s:m:h.
So why do we write our dates back to front in some countries and scrambled in the US?
I suspect it’s simply coz of how we say them and write them long form. e. 21st January 1982 or January 21st, 1982. But we never say 1982, January 21st.
As a non-US, I’d certainly prefer the back-to-front than the scrambled version if we can’t go for the ISO format.
The tag is not currently supported in any of the major browsers.
http://www.w3schools.com/tags/tag_menu.asp
! ! I love using these and I think we should use them more!
Thanks for the heads up on – I’ll be sure to start using that one as soon as possible too :)
abbr, time! I love using these and I think we should use them more!
Thanks for the heads up on menu – I’ll be sure to start using that one as soon as possible too :)
using HTML INPUT without attribute make impossible to use css selector like
input[type=text]for that one :(see sample http://jsfiddle.net/488Q8/
you fogot input types:
week
month
datetime
datetime-local
url
sample http://jsfiddle.net/dnGFp/
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.
Great, now I look like the idiot;
First missing elem – “menu”
Second – “nav”
Remainder:
, , , , , ,
To suggest that you should use the menu tag is a bit absurd, so no major browser supports it.
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.
I’d suggest rather than disagreeing with it, you’re choosing to be ignorant of it. At least the latter shows you understand they’re no longer supposed to be used for styling your text.
Fact of the matter is they have changed semantic meaning in HTML5 and in using them you’re changing the semantic meaning of your content if your only purpose of using them is to make text italic or bold (same actually applies to the ‘u’ tag which is no longer defined to be used to underline text).
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?
Very great article, and, i promise, i’ll use menu instead of ul ^^
The tag works just fine. HTML simply re-introduced it. I was deprecated in HTML 4.1. I am currently coding a new site that uses it for section commands.
Non-breaking hyphen (‑).
Thanks, I’ve learnt something new today!
I was hoping somebody would get a kick out of that.
dont forget about the new tag
*main tag
That’s pretty cool! I didn’t know <main> had been added to the spec. Thanks for sharing.
Thanks for such a useful post i will surely try the hyphen guild..XoXo
Great article!
Unfortunately, some tags aren’t supported for all browsers. So, it would be great verify them before using (http://html5test.com/).
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!
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.
constructive criticism > “Hey it’s absurd what you’re saying”
Nice article.
Thanks, I appreciate that. :)
Really great. I really didn’t knew about the non breaking space thing.
As I remember, menu elements are deprecated by HTML5. Did I get it wrong?
It still seems to be there in the spec, but it’s not supported in all major browsers yet.
http://www.w3.org/TR/html5/semantics.html#the-menu-element
Periodic Table of the Elements is down :(
Hi! The tag is not currently supported in any of the major browsers… Not sure I should use it
The “time” tag support is *VERY* limited. I wouldn’t even try to use it…
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/time
Support is actually really good. I think that MDN article is a bit out of date.
http://caniuse.com/#search=time
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”.
Great list of tags!
I can’t wait to start using some of these, especially and time and mark tags!
time tag will be great when pulling dates out of the database!!!
Thanks for a great post!
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.
Thanks a lot for the article.
Seems like a good list to use.
That’s nice! The one with the menu, I had not known. Thank you.
Put the abbreviations in uppercase. Please? :(
I liked your suggestion to use . Semantically, it makes a lot of sense. However, it is based on Title attribute which is driven by mouse hover. It is not accessible by Keyboard or touch.
Any ideas if there is a solution for such a scenario?
I liked your suggestion to use <abbr>. Semantically, it makes a lot of sense. However, it is based on Title attribute which is driven by mouse hover. It is not accessible by Keyboard or touch.
Any ideas if there is a solution for such a scenario?
Wow great!! I am a PHP developer and never noticed some of these tags. Thanks for this great info.