5 Obsolete Features in HTML5

On October the 28th, 2014, HTML5 became a W3C Recommendation. HTML5 certainly isn’t a new topic and a lot of developers are aware of its features: semantics, accessibility, APIs, and so on.

However, during the evolution of the standard, some elements, attributes, and APIs have been added and then changed or removed. Because it’s hard to keep up with all the news and updates in our field, some of you may have missed features that have been deprecated or removed from the specification. In this article we’ll cover five of them.

Obsolete vs. Deprecated

Before we delve into the features this article will cover, I want to be sure that you know the difference between deprecated, a term most of you might be familiar with, and obsolete.

The HTML 4.01 spec defines a deprecated feature as something you should not use, but that browsers should keep supporting. On the contrary, an obsolete feature is something that is listed for historical purposes only and no browser support is required.

The HTML5 specification updated the terminology. The term deprecated isn’t used anymore, and the term obsolete has a different meaning. In particular, obsolete refers to elements or attributes that will trigger warnings in conformance checkers. Although you should not use them, it’s possible that browsers support them and will do so for a long time, in harmony with the principle of backwards compatibility. Examples of older obsolete features are the border attribute on an img element and the name attribute on an a element.

To give you an idea of the difference of these terms in HTML 4.01 and HTML5, the font element is deprecated in HTML 4.01, and obsolete in HTML5.

With this in mind, let’s discuss five of these obsolete features.

1. The hgroup Element

The specification defined the hgroup element as typically used to group a set of one or more h1–h6 elements — to group, for example, a section title and an accompanying subtitle.

This element was introduced to easily create subtitles and address an important problem in the document outline algorithm. In fact, when grouping multiple heading elements in an hgroup, the outline algorithm was supposed to mask all but the highest level heading in the group from the resulting document outline.

I’ve been a fan of this element since I learned about it but, unfortunately, in April 2013 it was removed from the W3C’s specification. On SitePoint Craig Buckler covered this event in his article RIP HTML5 <hgroup> Element.

Now, all of that being said, what’s odd is that the WHATWG version of the spec, still includes hgroup. I prefer the W3C’s version of the spec, and the consensus seems to be that hgroup isn’t needed anymore.

2. The pubdate Attribute

The first drafts of the specification of the time element defined a pubdate attribute. It was a Boolean indicating that a given date was the publication date of the parent article element or, in the absence of a parent article element, of the whole document.

In this case, October 25, 2014 would be the publication date of the content inside the article element.

Unfortunately, pubdate was removed from the specification. However, you can still provide the same information by using the BlogPosting schema and its datePublished value, as shown in the following example:

3. The scoped Attribute

The scoped attribute, another Boolean, is intended for use on the style element, allowing you to indicate that the CSS inside the targeted style attribute is limited in application to the content inside the parent element of that same style element.

The goal of this attribute isn’t to violate the well-known principle of the separation of concerns, where you want to keep the structure, style, and behavior separate. Its aim is to address some specific use cases like adding styles that are only needed for a limited set of elements on a page, or adding user-defined styles to wiki or CMS content.

scoped is also intended to make the content “portable”, so you could take an entire chunk of HTML from one document, and put it in a new document (maybe injecting it via JavaScript, or syndicating it) and the styles would go with the content.

4. The command Element

The command element was a void element that represents a command that the user can invoke. Once a command was defined, other parts of the interface could refer to the same command, allowing many access points to a single feature, to share aspects such as the disabled state. There isn’t much information about this element but you should not care anyway because it’s now obsolete.

5. The center Element

You’re probably wondering why I’m mentioning this one, since this tag was already deprecated in HTML 4. The center element was a block-level element that allowed you to horizontally center all its content within its containing element. It was deprecated in favor of CSS’s text-align property, helping to keep presentational HTML out of a document.

In HTML5, this element is considered obsolete due to its presentational nature.

I’m sure that all of you are aware that this element should not be used but I’ve included it for a good reason: this post by Remy Sharp.

Several people, including me, thought he was being sarcastic but then he followed up with the blog post to explain his point of view. He explained that although center isn’t semantic and is obsolete, if you want to use an alternative, you have to employ a span or a div element, which are nonsemantic elements. But to use them you also need to use CSS to actually center their content. So, his reasoning is, why not use the center element instead?

Despite the fact that I understand his opinion and what he was trying to say, the center element isn’t something I’d use nor I’d suggest to anyone. But what do you think?

Conclusion

So to sum up: In case you missed some of news and discussions on HTML5 standards, and are still using one or more of these elements and attributes, you’re now aware that they are gone.

We’ve considered how sometimes elements and attributes that seemed useful at first didn’t generate much interest in developers or browser vendors. For this reason they have been removed from the specification, and thus are now obsolete.

I'm a (full-stack) web and app developer with more than 5 years' experience programming for the web using HTML, CSS, Sass, JavaScript, and PHP. I'm an expert of JavaScript and HTML5 APIs but my interests include web security, accessibility, performance, and SEO. I'm also a regular writer for several networks, speaker, and author of the books jQuery in Action, third edition and Instant jQuery Selectors.

Free Guide:

7 Habits of Successful CTOs

"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.

Thad Bloom

I kind of agree with the Remy on the center tag. Take this example: You are using WordPress and the client wants to center a line of text. They use the WYSIWYG editor to do so. Doing this adds style=”text-align: center” to your text, which is much uglier than a center tag IMHO.

http://g00glen00b.be g00glen00b

You should not use inline css either. You should create a class in your theme and apply styles to it. If your client decides after a while that he doesnt need the centered text, then you’re screwed if you used either the inline css or the center tag.

RG

Following your logic then WYSIWYG editors are obsolete. What is the point of using the buttons there then?

http://g00glen00b.be g00glen00b

Using the button tag means that you have a “call to action”. If you speak about semantics, its still better to apply the correct tags. However the center tag is not about semantics (it doesnt say a thing about the type of content) its about visualization.

OsakaWebbie

I think RG meant the buttons in the toolbars of WYSIWYG editors, which do things like bold, italic, colored text, font sizes, centering, etc., all directly in the local content, not by editing stylesheet files and corresponding spans. (I’m not for or against use of such things, as it depends on the situation; I’m just clarifying the conversation.)

http://g00glen00b.be g00glen00b

Imho WYSIWYG editors could be used, but depending on how they work. I mean, if they use inline CSS or <b>, <u>, <i> and <center> stuff, then you shouldn’t use them imho.

Frederik Krautwald

Yes, WYSIWYG editors should be blown to smithereens.

http://johndehope.weebly.com John DeHope

I think you’re comment is too broad. WYSIWG editors that allow you to apply ad hoc formatting should be blown to smithereens, agreed. But editors which allow you to flag semantic meaning should be embraced. Then that semantic meaning can by styled or themed. I’d love a version of MS Word (or whatever text document editor you prefer) that got rid of ad hoc formatting too. Selecting a word in MS Word and clicking the “B” button to make it bold is the intellectual equivalent of the <b> tag in HTML.

Frederik Krautwald

Yes, I was being slightly curt (it was late). WYSIWYG editors should, of course, work similar to the way graphic design software, like InDesign, etc., work, i.e., by having defined styles that can be applied to sections of content, pretty much the same way CSS classes can be applied to HTML elements. So if an emphasis style is applied to some content, then the actual rendering will be according to the style’s definition.

mikehaseler

Please! You should use inline Css where the css only applies to that file. Code should be where it is most relevant, and where it only applies to one part of a file – then it is good practice to put it in the html where it can be seen.

http://g00glen00b.be g00glen00b

No, that’s just completely against what HTML and CSS are trying to do (which is trying to separate the styling from the markup/description of the content).

The meaning of your text is not necessarily linked to the styling of your text. For example, an important text might be colored red today, but maybe tomorrow you decide that it should be black text on a red background, good job fixing that with inline CSS. While the text is in both cases “important text”, it does not necessarily have the ame style. They should be decoupled.

http://www.cdelaney.com/ Colm Delaney

A better solution than either would be add a rule “.center {text-align: center}” to your style sheet, then add the class “center” to any element that needs to be centered.

It’s best to plan your style sheets properly and avoid such ad-hoc visual styling altogether. But in the real world, these come in handy from time to time. Most of my projects have at least a dozen such one-liners in the style sheet.

josueochoa

FTW

Aurelio De Rosa

It’s quite weird to see so many fans of the humble element, I didn’t expect that.

http://www.dynamicsitesolutions.com/ Kravimir

Not everyone cares as much about semantic markup as some of us do. I too greatly miss the hgroup element.

JoshuaMuheim

I’m working in a foundation that strives to make the web accessible to everyone, e.g blind people. We test a lot of websites created by huge companies, and it’s devastating how crappy their HTML is. IMHO it’s great that everyone can contribute to the internet and that HTML is quite an easy to learn and use language, but there are so many pseudo professional webmasters that I often want to cry, because all those people depending on clean HTML (e.g people using screen readers) get lost very quickly because of messy HTML.

http://www.dynamicsitesolutions.com/ Kravimir

Do you see issues like “divitis” and use of seemingly random heading levels?

I’m glad someone else cares. I work towards achieving WCAG AA-level compliance in most of my projects. I frequently point out that some of the color choices for text by designers lack sufficient contrast.

Christian Z.

DIVitis is everywhere. And so very, very few people know how to use header tags properly.

Christian Z.

There’s some pretty atrocious HTML out there. I recently completed a contract where I coded the front page of a website in beautiful, semantic HTML5. I then turned the code over to the company, whereupon somebody over there promptly rendered it into the most atrocious legacy DIVitis code.

Mr. Dohickey

The reason it it’s a pain in the ass to center an image using CSS whereby using the center tag works flawlessly.

Alessandro Pellizzari

display: block;margin: 0 auto;
Doesn’t seem such a hassle…

mikehaseler

I hear W3C are going to ban unnecessary characters in the next version of HTML. Q will be deprecated for kw, ph must be written f, etc.

Of course everyone will just ignore them – just they will over the center tag which will continue to be supported by browsers.

jokeyrhyme

The scoped style element was made obsolete by ShadowDOM and WebComponents. So it is possible to achieve the same effect through other means.

JoshuaMuheim

The reason why I’d never use the center element is that I never know, how my content will look in the future. There is no such thing like “center” in semantics, it’s simply a visual property. A quote typically is centered, but maybe sometime in the future you want it aligned right? So using a container with a class (e.g. div.quote) and styling it as needed is much more appropriate than using a center tag.

I don’t know why I’m really explaining this here… Is there really somebody left not knowing this inside out already?

http://www.dharne.com/ Dharne and Company

Thanks for sharing this wonderful post! This really adds on some good and useful points to consider.

Petit Paul

I keep using “border = 0” in the img tag as older versions of IE were adding an hugly 2px blue border to an img when it was inside a link element if no border was specified, even if not hovered on. Since I’m not sure when IE stopped displaying that behaviour, I keep adding it. Cost is minimal anyway.

Aurelio De Rosa

Why aren’t you using CSS for that? I mean isn’t something like

a img { border: none; }

enough?

Petit Paul

Sure and I do. Force of the habit, I guess. I’m not sure if older versions of IE do enforce the style correctly, though…

Mr. Dohickey

If you have a portfolio, for instance, with 100 images, putting that on each img tag would be way more costly than the CSS alternative as shown by Aurelio De Rosa below.

samdutton

Nice article!

Another one: media attribute for in (though now available for ). Demo at simpl.info/videomedia.

ultimatedelman

Say what you will about the element, but before you get on your high horse about why you’d never use it, inspect the wrapper around Google’s logo on their homepage…

Why do people keep citing Google Search’s landing page as an example for acceptable technique? It’s one of the highest traffic pages in all the Web. They’ve optimized the code to an *extreme* level that’s not really appropriate for the website of a small- or medium-sized business.

Aurelio De Rosa

Hi Sam, and thank you very much for your comment. To be honest I didn’t even recall of such attribute on the ‘s element, so that’s a good point. Can you point me on the reasons why it was removed? I know about the media attribute of ‘s , so I’m trying to understand the reasons behind this difference.

I think the general feeling is that adaptive streaming with Media Source Extensions is a better option for handling connectivity issues.

Kyle Thomas

I really miss the element. It was just so quick, easy and to the point! They should bring it back.

Aurelio De Rosa

Hi.

If you really want, you can use it because browsers still support this element.

Mitchell Teixeira

Sometimes no amount of CSS is such a quick problem solver in so many situations as . When you just need to get the job done and move on, it is dependable and consistent. Sure, it’s a timebomb, but isn’t everything else? Besides, most WYSIWYG editors can’t go back and clean up old or nested formatting, esp. not the WordPress one. I frequently have to go behind clients and clean out nested or useless formatting tags added by that lousy WYSIWYG editor.

http://rdksites.net/art/example Dave Keays

Center tag or do the same thing with text align? If you aren’t leaving the visual attribute (call it what you will) open then; 6 of 1, 1/2 dozen of another. Too many fingers pointing and people screaming things like “you should have” or “its supposed to”. Has anybody ever heard of “context” before they started condemning others for not being proper?

http://w3guy.com Agbonghama Collins

+1 for the tag.

The tag should return back to HTML5 or in future version of HTML.

SelenIT

In his artice in defense of , Remy missed one more important point: currently, seems to be the only cross-browser way to center both inline- and block-level content of an element (including their margins), without changing other parts of that content behavior (as, e.g., Flexbox does). Of course, this possibility should be in CSS, not in the markup. But it should be there:)

vaFyreHeart

I particularly disappointed to lose scoped. That was one of my most used HTML5 features (other than new input types), and one of my favorite questions to ask interviewees.

is my most-used holdover from HTML2, though I use it very rarely. Occasionally, inline formatting is a necessity, and is far easier than .

Unashamed

I unashamedly use the tag all the time, and it works in most situations across a multitude of browsers, from the ancient to the newest.

Aurelio De Rosa

Thank you very much for the links Sam.

Dhruvanshi

Nice article on HTML5. My team members are using HTML5 features to build a site and HTML5 is very easy and effective to use.

Best regards,
Dhruvanshi

http://ericnjanga.com Eric Njanga

Very refreshing. I confess that I was no longer using any of these five elements, but it is empowering to know what shouldn’t be used.
Thank you Aurelio.

mikehaseler

It is good practice to use the tags that are most appropriate. yes in some environments the right approach is to move as much to css as possible, but likewise in other environments the right approach is to use tags like center and even font.

The problem is not what is “right or wrong” – but that some people wrongly think there is only one way to do things and only one type of user producing only one type of website who needs only one approach. If that were true – the internet would be a pretty boring place!

Christian Z.

I missed the HGROUP element when it was taken away (deprecated?) until I learned about the SUBHEAD element, at which time I realized I hadn’t properly understood the HGROUP element, and that maybe the SUBHEAD element was a more sensible replacement. A subhead is actually something different conceptually than an H2 – H6 element. Created a Codepen a while back to test it here: http://codepen.io/WebDevCA/pen/wzyIH

http://qwertjsblog.altervista.org/ Matteo Capucci

Well, we have <strong>, why not ? Almost everything feels better than a when it comes to neutral elements. I read it in a semantic fashion, and it’s not so bad.
Anyway, I actually never used it because of its deprectated status…

blackHoleOblivion

The ‘element’ is a relic of a time of immature CSS, a hack of sorts. As the specs are ever-evolving, we should hope for a better solution than what’s available today and accept that while it’s still a bit dirty, the separation of structure and presentation is a wise endeavor.

As for , I understand the decision to make it obsolete in order to align subheaders with associated content (and not a prior header, as seen in an HTML Outline), but remember that in some cases you really do want the non-heading content associated with the subheader element; it depends how it’s written. That said, most people won’t write in that style and life is just easier not convoluting the situation.

mikehaseler

I was gullible – I assumed as a mere website producer – those writing these standards knew what they were talking about and that there must be some point to this change. After trying (whatever the style code is) I realised that if there wasn’t a center tag I’d just have to create something with precisely the same functionality and that those trying to force these changes are just numpties or worse power crazed people who just want to make change for changes sake.

So, today as I reviewed the work needed to make all the ridiculous, needless & pointless changes and realised that none at all were necessary as browsers would continue to support tags like center.

I decided that HTML 6 should have a new tag W3C

Rashid Hamid

css scoped not supported to chrome. How to use scoped or any alternative of for chrome.