Understanding HTML5 semantics – Part 3: Changed and absent elements

In the two previous articles on HTML5 semantics, and document structure and global attributes, I discussed some of the new elements added to the HTML5 specification along with their semantic meaning. I also showed you the differences between the HTML4 and the HTML5 document structure, including the addition of new global attributes. In this article, I'll discuss some of the changes to older elements: some are obsolete, some have changed in semantic meaning, and a few have been reintroduced.

Remember that HTML5 is still a work in progress. Some of what I tell you today could still change before the spec is declared complete. It's always a good idea to keep an eye on both the W3C page about changes as well as the WHATWG's spec for developers.

We've talked about some of the new elements and attributes added in the HTML5 spec, but there are also quite a few that we should no longer use. These features have been completely removed from the spec—either because the features are presentational and have a CSS-based equivalent, the features are confusing, they're problematic for usability or accessibility, or we now have a better method.

Purely presentational

The effects these elements rendered was purely presentational. Instead, implement these effects using CSS styles:

• basefont
• big – Consider using a heading element if it's semantically appropriate, otherwise a class is more appropriate if you're simply using big to increase size.
• blink – (You can use animations if you really want to replace this—but hopefully you won't.)
• center
• font
• marquee – CSS transitions and animations are more appropriate ways to create such an effect.
• multicol
• nobr
• spacer
• strike – Use del if the element is marking an edit, otherwise you should use s (which is for content that is no longer accurate or relevant).
• tt

Bad for usability and accessibility

I'm guessing most of you dropped these long ago, but in case you're still using them, you should not be. Instead, if it's necessary, use iframe instead:

• frame
• frameset
• noframes

Rarely used and confusing elements

Since the following elements were either not used often, were confusing to authors or have other elements that can no handle their function, they should not be used in modern web sites:

• acronym – Not included, because it has created a lot of confusion. Authors are to use abbr for abbreviations.
• isindex – Usage can be replaced by an explicit form and text field combination.
• applet – Obsoleted in favor of embed or object .
• dir – Obsolete. You should use ul instead.

noscript – This element should only be used in HTML5 when you're using HTML syntax. Do not include it in the XML syntax.

Further deprecated elements and attributes

Here are a few more of the "not to be used" attributes and elements:

• listing - Use pre and code instead.
• noembed – Use object and embed when fallback is necessary.
• plaintext - Use the text/plain MIME type instead.
• name – This attribute should no longer be used on a , embed , or option elements. You should use an ID instead.
• longdesc – This attribute should no longer be used on img or iframe elements. However, keep an eye on this one as there's still some debate going on.
• summary – This should no longer be used on table elements. There are several suggestions on how to mark up this content in the Techniques for describing tables section of the HTML Living Standard site.
• scope – Do not use it on td elements.

For an exhaustive list, keep your eye on non-confirming features: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features 

Previously absent, but now recovered!

One of the tenets of the HTML5 specs has been "Pave the cowpaths!" I love this. That means, if a feature is being used extensively by authors, has browser support everywhere, yet isn't part of the spec, the spec should adopt it instead of forbid it. (See HTML Design Principles for more information.) For this reason, several elements have been added to, or added back into, the spec after being deprecated—either purposely or accidentally.

embed – Browsers have supported the embed element for years. Yet, if you were embedding plugin content (most notably Flash, Silverlight or QuickTime), though the rendering was not a problem, your page would not validate with the embed tag included. This caused all kinds of javascript gymnastics—the most well-known being the SWFObject. In HTML5, the embed element has been included in the spec.

Read more about the embed element: http://developers.whatwg.org/the-iframe-element.html#the-embed-element.

• iframe – You probably noticed above, when mentioning that frame has been removed, I stated that you could use an iframe to replace it. Though the iframe element was omitted from the HTML 4.01 Strict DTD (the thought was it would easily be replaced by the object element), an awareness soon came about: you sometimes need to embed an HTML document inside another one. HTML5 has brought the iframe back into the land of the legal.

There are several interesting attributes for an iframe , here are three:

• seamless – A Boolean attribute that makes the web page render the iframe seamlessly with the content around it.
• sandbox – This attribute enables a set of extra restrictions on any content in the iframe . This allows you to enable or disable forms and scripts, prevent popups from sandboxed content, secure plugins, and allow or prevent links from targeting other browsing contexts. Be sure to read up on this attribute and understand the security implications before using it.
• target – This attribute has returned. In HTML4, the target attribute was deprecated as presentational (or to be used on framesets, which were also deprecated). With the return of the iframe , there is once again a need to allow hyperlinks to alter the content of an iframe via the target attribute. The target attribute can also be used on a , area and base as well.

Read more about the iframe element: http://developers.whatwg.org/the-iframe-element.html#the-iframe-element.

Changes to lists – I really like what has been done with lists as well. There are several changes:

• In HTML4, we were not allowed to place an empty ol or ul into the page—they had to contain at least one li . And why in the world would you want an empty list? In today's dynamic world, you may need to fill the lists in with scripts. That's now okay.
• start – This attribute allows you to set a value for an ol to start with. Perhaps you've had to end a list to add some other information on the page, then pick up on the list right at the value where you left off. You can use the start attribute to tell the browser where to restart the numbering.

• reversed – A boolean attribute added for ol elements. And it does exactly what it sounds like—it reverses the order of the list numbering causing it to count down rather than up. (It does not reverse the order your list content is displayed in).

Rendered as:

• value – This attribute might be another way—for now—to show your list items reversed—or in any order you need them to be. This includes two list items with the same number. The value attribute gives a list item a specific number value. The value attribute was deprecated in HTML4 (mistakenly) and due to the fact that it was previously an accepted value, it has great support across browsers.
  When using the value attribute, you can number all list items, as in the case of showing rankings where there is a tied value.

Or more simply, since the list will begin with 1 and continue to automatically increment, you could leave off the beginning value and the values beyond the tied value:

• menu – This element has been redefined to be useful for toolbars and context menus. It can also contain list items where useful.

There were elements many of us thought of as deprecated. We had more semantically exact elements (elements like b , i , u , small , etc.). Oh happy day—they're back! But they have evolved into a slightly different meaning now.

• b, strong – Long, long ago, in a world far, far away, we replaced the b element—because it was purely presentational—with the strong element. That's changed now. The strong element now represents importance rather than strong emphasis. The b element should be used to draw attention to a difference in styling, without an associated difference in voice or mood. The b element might be used for key words in a document abstract, product names in a review, spans of text whose presentation should be bold—but not emphasized with assistive technology.
  I've also seen it used to denote stylistic differences in a heading. Perhaps:

• You can nest strong elements to express relative importance as well. From the HTML Living Standard, here's an example of a warning notice in a game:

• i, em – In the same way as b , i no longer expresses an italic styling, but instead is used to represent an idiomatic phrase from another language, terms from taxonomies, technical terms, ship names, etc. In other words, it's offset from the normal prose, but is not meant to denote emphasis.
  Conversely, the em element is meant to stress emphasis. As above, with the strong element, the level of nesting indicates the strength of the emphasis.

I will be interested to see how the b , strong , i and em elements fare with these new semantic changes. The changes are somewhat subjective and different authors may vary their choices. Time will tell.

• small – Though the big element has been removed, the small element has simply been redefined. Instead of small being related to size, you now need to think of it as the "small print." This is typically disclaimers, caveats, legalese or copyrights. It can be used for licensing requirements. It doesn't lower the importance of the text, or even necessarily make it smaller in size. You can style it in any way you like.
  It should be used for short runs of text, not multiple paragraphs or sections of text. An entire page giving legal information about your site would not be marked up with the small element. The legal information would, in that case, be the main content of the page.
• u – Though the u element has typically been used to underline—and has been strongly recommended against (so as not to confuse people who expect a link)—it has been reintroduced with an extremely limited focus. In Chinese, a proper name mark should be underlined. Also, when showing misspellings, the expected visual mark is an underline. These are perfectly acceptable uses of the u element.
• hr – Though we've used the hr element (but sparingly) for years, it's meaning has slightly changed. It now represents a thematic, paragraph-level break. It should be used to separate different topics within a section of prose, or between scenes of a novel—but not to separate sections of a site. The styling can be completely changed from an unattractive horizontal rule to a lovely flourish of some sort with CSS. Simply remove the borders, add margins and whatever background-image you'd like to use.
• cite – The overall usage of cite, as a title of a work, hasn't changed in HTML5. But the method used in HTML4, to mark up the name of a person who stated something you've placed in the page is no longer considered conforming. Yes, I've done this—on my own site. I really don't understand, with the whole "Pave the Cowpaths" mantra, why this use would be banned. It will be interesting to see if this remains in the spec. I may not be marking up new sites this way, but I'm not changing anything yet.
• dl – Similarly, the dl element should no longer be used to mark up dialogue. It's simply an association list of name-value groups.
• br – The break element should not be used for separating thematic groups in a paragraph or for simply creating more empty space. Use it as a line break that is actually part of the content—like in poetry and addresses.

There are a few new text elements I'd like to call attention to:

• wbr – This represents a line break opportunity. It is used to suggest wrapping points when, for effect, you have a phrase written as a single long word. Maybe you have a long URL. Or perhaps you're writing out some code and want to choose where the break points might be—determined by the space within the user agent. The HTML Living Spec has the following example:

• code – A fragment of computer code. This could be an XML element name, a filename, a computer program, or any other string that a computer would recognize.
• mark – The mark element is used rather like a highlight. It is aimed at drawing attention to what is relevant to the user. A great example is search results—the mark element could stylistically change the word the user was searching for every time it appears in the search results.

For more information and examples for properly marking up text elements, see the WhatWG spec usage summary.

Remember, things can still slightly change, and of course, this is not exhaustive. If you read the WhatWG specs made for developers (without all the error handling information for browsers), you may find some interesting elements we haven't had time to touch on yet ( progress , meter , time , ruby , bdi , details and summary , etc). We have a big HTML5 universe to explore—put on your spacesuit and have a good time!