By Craig Buckler

RIP HTML5 <hgroup> Element

By Craig Buckler

Do you use the hgroup element in your mark-up? It’s probably best not to — the tag is being dropped from the HTML5 specification.

We normally think of HTML5 specifications receiving additional features, such as the new <main> element. However, elements can be removed if they offer no compelling benefits.

hgroup represented the heading of a section and normally contained two or more h1 to h6 child elements, e.g.

<h1>My Main Heading</h1>
<h2>A sub-heading</h2>

Did you ever use it? I can recall one occasion and, even then, it was primarily for use as a CSS hook and could have easily been a div or section. The request to remove it came from Steve Faulkner:

  • hgroup does not convey clearly that a particular heading is a sub-heading
  • heading semantics are still exposed regardless of an outer hgroup
  • the specification stated all hgroup headings must be concatenated for accessibility, i.e. the title would become “My Main Heading A sub-heading”
  • hgroup did not have at least two reasonably complete interoperable implementations, i.e. it was a div by another name
  • few sites implement the hgroup element

No reasonable use-cases were forthcoming so hgroup will ultimately disappear from the HTML5 specification. There is a possibility it will morph into another element offering better semantics, but those debates are yet to occur.

No … I Use hgroup On Every Page!

The removal of hgroup will make little difference to your daily coding efforts. Most browsers already support it and, even in a new applications, hgroup would be treated the same as any unknown tag. That said, it’s probably best to avoid using hgroup in new projects since HTML validators will eventually report an error.

  • Ran

    Alas, the hgroup element is used by several WordPress themes, including the default themes (twenty twelve and twenty eleven), as well as in other popular starter themes like “underscores” ( for example…

    • Thanks Ran — I didn’t realize.

      Fortunately, the themes won’t break overnight — or ever. Browsers will happily continue to parse hgroup as just another element.

    • And those themes will be updated to include this change so everybody will be happy :)

      • Tuomas

        I found mention that Twenty Thirteen dropped it now during development, but Twelve/Ten will probably retain it.

  • Efren

    I think that not too many people will miss it :/

    • I won’t miss it, and it’s no problem to switch them out of existing projects, but I actually thought it was generally a good way to define headings and have been using it since introduction.

  • Kell

    Never used it.

  • steve faulkner

    Note: the W3C Validator has been updated to reflect hgroup being obsolete in HTML5. When a hgroup element is found it produces the following error:

    Error: The hgroup element is obsolete. To mark up subheadings, consider either just putting the subheading into a p element after the h1-h6 element containing the main heading, or else putting the subheading directly within the h1-h6 element containing the main heading, but separated from the main heading by punctuation and/or within, for example, a span class=”subheading” element with differentiated styling. To group headings and subheadings, alternative titles, or taglines, consider using the header or div elements.

    • Thanks Steve. Good to see that the validator has been updated so quickly.

  • I wish you would make your minds up !
    Surely HTML5 is not experimental any more.
    I have been using the element on my website, and not so long ago the time date time element was dropped and did not validate, but low and behold it came back again.
    The element was not doing any harm, ok some people did not know the proper use for it,
    but I hope it comes back again.
    Neil Ormsby

    • steve faulkner

      Hi Neil,

      The element was doing harm as it promoted the use of multiple sibling hx’s. The time element was a different matter, that was due to a fit of hubris on on the former W3C HTML editor’s part. Validation of the element was not affected, it was only removed from the editor’s draft for a week, then put back in.

      Part of the process of getting HTML5 to recommendation is removing stuff that is not implemented. It is clearly stated in the HTML5 CR spec:

      The following features are at risk and may be removed due to lack of implementation.

      hgroup is one of those features listed and it has been removed. There is a long and voluminous history to its removal, and it is not something that was decided on a whim.

      • Christian

        “as it promoted the use of multiple sibling hx’s”

        Why is that a problem? Sometimes it makes sense to have an H2 followed by an H3, or an H3 then an H4. We have the W3C making too many decisions based on the fact that people don’t know how to code correctly, including not knowing how to properly structure their headers. “Here’s elements H1 – H6 to use . . . but, uh, don’t ever use more than one at a time.”

        Steve, you may not quite be getting that you are recommending that people use certain elements and then implying they are stupid for using them.

        BTW, I use the TIME element as well and was one of the people that requested that it stay.

  • Koder

    Thank U idiots for making markup more messier by having me to rename the hgroup to div/class .hgroup & comments !!!

  • Kenny Landes

    I might have used it once or twice, but it was really just extra markup. The only benefit was it only sectioned the document once instead of twice.

    I am glad to see HTML5 functioning as a living standard, though. My understanding is that it’s not really “HTML5” anymore, just HTML, and it will continue to evolve as just that.

  • I keep forgetting to use it and, thank goodness, inertia prevented me from correcting it later. I could see it’s usefulness, but I doubt I shall miss it.

  • ppjm

    I do wish that the W3C crew would stop doing this. hgroup was useful, I have employed it in the templates on a score of sites, now I will have to update the templates. Why? Because some fool couldn’t leave alone.

    hgroup was a good way to indicate a sub-heading which was not intended for the index/table of contents/sitemap/linear navigation/etc.

    One handy use was in creating site-wide page headings: h1 for the company name, say, then h2 for a snappy 5 words outlining what the company did, all made nice and pretty with your choice of downloadable web font. hgroup then wrapped them and excluded the h2 from annoying screen reader users.

    Sometimes the standards guys just seem to want to fiddle, without considering the consequences properly. Blurgh.

    • steve faulkner

      Hi ppjm,

      “hgroup then wrapped them and excluded the h2 from annoying screen reader users.”

      Unfortunately it didn’t:
      1. it wasn’t implemented
      2. if it was implemented it wasn’t defined to do what you describe.

      You can do the what you describe by using the markup in the 3rd example in the spec section Subheadings, subtitles, alternative titles and taglines.

      • ppjm

        I couldn’t be bothered firing up my collection of various screen readers to investigate their treatment (or not) of the hgroup element, I couldn’t really be bothered with the argument. The purpose of hgroup was clearly to group headers so that only one would be seen as structural. Out of curiousity, I did look at a page with hgroup using the Firefox readability extension. Only the first of the h(n) headings in a hgroup is displayed. I do know that numerous other tools have similar behaviour, I know because I have used them.

        I cannot think of any good argument to remove hgroup. It fulfilled a clear semantic purpose, this is now absent from html. In general, established elements should not be removed unless they are clearly obsolete, superseded or bad practice. hgroup was none of those.

        I have worked in software development for the best part of thirty years. My experience has often been that 90% of the time is was spent on 10% of a project’s requirements, with minor arguments amounting to little more than different personal views getting magnified to great matters of ego. I suspect that hgroup’s fate has been sealed in such a manner.

        As for the “HTML 5.1 Nightly
        A vocabulary and associated APIs for HTML and XHTML
        Editor’s Draft 27 April 2013” document that you have referred me to?

        What is there to say?

        I have rarely seen so much bad practice passed of by way of recommendation. Unclosed tags (opening li tags without closing li tags, opening p tags without closing p tags, opening th and tr tags without closing th and tr tags, etc.), navigation lists in paragraphs rather than lists, etc. A W3C document which points out lots of missing semantics from the html standard, and then subsides into recommending make do and mend with a bunch of dodgy definition lists.


        I suspect that if this is indicative of the direction that html5 is taking, that the industry is going to spend a considerable period doing damage to itself.

      • steve faulkner

        While feeling that it is best not to feed a troll, some of your rant needs to be rebutted:
        For all your thirty years of work in software development you appear to have little understanding of how browsers and AT interact and how the accessibility API implementations in browsers effect the information available to AT.
        I work directly with browser and AT implementers to implement the accessibility layer semantics of HTML and can confirm hgroup does nothing in NVDA, JAWS, Window Eyes, Orca, VoiceOver, Supernova, in fact it does nothing in any screen reader. The reason for this is that no browser (webkit, IE, Firefox, Chrome etc) has implemented the accessibility layer semantics of hgroup. If they had it would result in exactly the opposite of what you mistakenly claim. But hey you can’t be bothered to comprehend that.

        On unclosed elements: If you had any understanding of how browsers actually parse HTML you would know that it makes no difference to browsers if end tags are present for the elements you mention. Which is why they are not required, but if it makes you feel better or superior then by all means provide end tags where they are not needed.

Get the latest in Front-end, once a week, for free.