The hgroup hokey cokey

by .

As you may well have heard this week, hgroup has been in, out and in the spec again, while members of the W3C and others have truly been shaking it all about. If you’ve missed this latest merry dance then please head on over to the W3 bug report page to help get a clearer indication.

To offer a quick recap, hgroup was removed from the W3C specification only (not the WHATWG spec) by Hixie at the request of Steve Faulkner. The co-chairs requested the issue be reverted following multiple requests from the likes of Tab and Tantek. The current status at the time of writing is that hgroup is in the spec.

It seems that the future of hgroup will be decided during the HTML5 spec last call review which is expected to start on or around May 22nd 2011.

One of the main reasons for this element being removed was because some people felt that it was only in the spec was to keep the outline algorithm happy and that it didn’t really offer much else in the way of semantics. It has also been suggested that people were still struggling to understand how to implement it correctly. If, however, you need your memory jogging then we suggest reading our post on hgroup from last year.

Far be it from us to get involved in the political wrangling (and knob waving) of the W3C, therefore when news of this broke we doctors fired a few emails between each other discussing what was going on and what we thought should be the next logical step. The outcome from these emails showed that there was no clear majority. Some of the doctors, myself included, thought that the element was a handy addition to the spec and should be something that we fought to keep. Others, like Bruce, have made no qualms about their dislike for this particular element.

Regardless, we decided to see if we could solve this issue by offering up alternative solutions. Below are a few of the suggestions (and issues) that came out of the conversation. We understand that some of these suggestions come with their own issues and the consequences maybe haven’t been fully thought through, but the aim of this is to start a conversion, not provide a final answer.

      <h1>Title goes here</h1>
      <h2>Subtitle of article</h2>
    <p><time datetime="2010-03-20">20th March, 2010</time></p>
  <p>Lorem Ipsum dolor set amet...</p>
How hgroup currently works, for comparison

Subtitle within header

  <p>Lorem Ipsum dolor set amet...</p>

The method suggested above is probably the closest example to what we currently have with regards to hgroup. Within this code example we have an heading level and p tag within the header element.

Although this might seem fairly straight forward, it does become more complicated if we have further elements within the header; additional p tags, spans etc.

Highest ranking heading takes precedence

    <h4>Intro subtitle</h1>
    <h1>Title goes here</h1>
    <h3>by John Smith</h3>
    <p><time datetime="2010-03-20">20th March, 2010</time></p>
  <p>Lorem Ipsum dolor set amet...</p>

Taking the previous example a bit further, here we have multiple headings within header and the machine could recognise that the h1 is the highest ranking and should be used in the outline. Other headings are excluded, with the exception of the h2 within nav as it is a sectioning content element and therefore still affects outline.

This allows the developer to have multiple subtitles of varying importance without affecting the outline. The drawback of this is the use of headings isn’t very intuitive when lower ranking headings can appear anywhere within header. Thankfully we still have ideas for other alternatives.

Span subtitle within header

    <h1>Title <span>Subtitle</span></h1>
  <p>Lorem Ipsum dolor set amet...</p>

This next technique is probably similar to something that you might have used before when coding up a page in HTML4, providing something of a natural progression, paving the cowpaths if you will. As the span is within the heading element it makes it clear that it is associated with the heading.

Some of the doctors are not convinced this is the correct way to progress and therefore looked for another alternative.

Introducing the subtitle

    <h1>Title <span subtitle>Subtitle</span></h1>
  <p>Lorem Ipsum dolor set amet...</p>

This example is almost identical to the example provided above. The only difference here is that we’ve added a subtitle attribute to help assistive software make the connection between heading and subtitle. Again, some Doctors are not completely comfortable with nesting a subtitle within a heading element.

It was also suggested combining this example and the first to come up with a better outcome. Whereby a developer would include a heading and p tag, marked up with the subtitle attribute, within the header element.

For attribute within header

    <h1 id="title">Title</h1>
    <p for="title">Subtitle</p>
  <p>Lorem Ipsum dolor set amet...</p>

Now for something totally different. The above example borrows an idea from forms using the for attribute. in HTML5, a number of elements which were previously required to be within a form element can now be located anywhere on the page and associated with a form using a form attribute pointing at the id of its form owner. This example extends borrows the idea an applying it to use with another attribute and element.

In our example the p tag is owned by the heading element. The interesting thing with this method, along with the forms, is that the subtitle wouldn’t necessarily have to be nested within the header, as assistive technology would still be able to associated which heading it belonged too.

What’s next and your suggestions

Issue 164 on the W3C tracker offers some further suggestions to how hgroup could be removed, modified or otherwise changed. Some of those are similar or the same as those we’ve mentioned above but now you’ve seen our suggestions and perhaps perused those in issue 164, so why not let us know your suggestions below in the comments.

This is a fairly big issue and one that a lot of people are still obviously undecided about, so here is your chance to seize an opportunity because, you never know, your suggestion could become standard practice.

58 Responses on the article “The hgroup hokey cokey”

  • Ian Devlin says:

    I must admit that I like hgroup and see nothing wrong with it. It cleanly groups together any hn elements (as long as it’s used properly – which I suspect is one of the problems with it).

    I’m not too keen on having a span element, or any other element for that matter, contained within a hn element. They should contain the relevant text only.

    As regards the “for attribute within header” suggestion, how deep can you go? Surely it’s then possible to have a subtitle for a subtitle that’s a subtitle for a title, which could get a bit messy. Using hgroup here, with the appropriately numbered h elements would make the hierarchy clear.

    But, as I and you mentioned, the issues with most of this stuff is people’s understanding of using it correctly. As a curator of HTML5 Gallery, I do see it being mis-used occasionally, but then again is it not our job to help educate?

    I say keep hgroup and embrace it.

  • @jack wrote:

    “Far be it from us to get involved in the political wrangling (and knob waving) of the W3C”

    Politics is part of the development of standards, the statement above is a politcal statement, it was not the W3C that was wrangling and nob waving.

  • Richard says:

    Either way, please remember many screen reader users navigate via headings. The more you mess, the more complicated it gets, the more headings get miss-used. The more our screen reader user gets confused.

  • Many of these alternatives require the use of <header> to try and group headings. It’s not obvious that any of the proposals here or elsewhere are going to be any more intuitive than <hgroup> is.

    The problems I can see with the id/for attribute idea:

    * A <header>, or other area of the source, may contain some heading elements that are subheadings and others that are not. The lack of explicit grouping may be a bit confusing.
    * Easy to accidentally not have the associated elements as siblings in the source.
    * Requires unique ids for each heading that may have a subheading.
    * May be less practical than <hgroup> for CMS-based development.
    * Likely that people will still want to add a class to the subheading for styling purposes.
    * Doesn’t place as many constraints on the type of elements than can be marked as subheadings of headings.
    * Nothing stopping you from using a <h1> as a subheading of a <h4> or maybe even a <p>.

    It just seems that <hgroup> doesn’t have any of these shortcomings.

    It would be a shame if <hgroup> is replaced by an alternative that hasn’t been demonstrated to overcome <hgroup>‘s perceived short-comings.

    Just to add some of Hixie’s comments and rebuttals to this discussion:

  • Elpie says:

    I like hgroup but am concerned about the confusion it causes. The biggest issue, in my opinion, is that many people are assuming that because it exists it must be used.

    People who have not had to jump through hoops in using headers with associated subtitles, while creating a logical document outline are unlikely to ever need to use it. Those of us who use headers and subtitles, and who have long wished for a semantic way of grouping these, without screwing up the outline, now have the means to do this.

    Education and understanding is what is needed. hgroup is fine as is and I hope it will stay that way.

  • Zielun says:

    If the problem is with misusage I think more attention should be put on how to educate people to let them understand how to use the element properly. The hgroup approach is the simplest solution to use I can imagine and don’t see a real reason to remove or replace it with less intuitive or more troublesome one.

  • zcorpan says:

    “in HTML5, a number of elements which were previously required to be within a form element can now be located anywhere on the page and associated with a form using a for attribute pointing at the id of its form owner.”

    You’re thinking of the form=”” attribute.

  • @zcorpan, oops yeah, my fault that one. Thought we were talking about the @for so removed the m in an edit!

  • Marcus Downing says:

    There are many cases when you wouldn’t choose to use an , but that doesn’t invalidate the cases where it does apply. Similarly, there are people who will never touch a in their lives, but it still serves a purpose and belongs in the spec.

    My understanding is that is a more general-purpose grouping of things that might belong in the heading, such as author, date, categories, breadcrumbs, buttons labelled “Delete” or “I Like This”, and so on. is much more specific, grouping a title, optional subtitle and potentially other title-like fields.

    Given the thousands of websites, books and so on advocating , the browsers that implement it and the sites that already use it, removing it from the spec would simply cause the spec to diverge from reality. The result would be a few years in which the spec was out of touch with real use, before admitting defeat and accepting back in again. That doesn’t sound helpful for the cause of standards-compliance in general.

  • Marcus Downing says:

    Ahem. Let me try that again:

    My understanding is that <header> is a more general-purpose grouping of things that might belong in the heading, such as author, date, categories, breadcrumbs, buttons labelled “Delete” or “I Like This”, and so on. <hgroup>is much more specific, grouping a title, optional subtitle and potentially other title-like fields.

  • @marcus

    “Given the thousands of websites, books and so on advocating , the browsers that implement it and the sites that already use it, removing it from the spec would simply cause the spec to diverge from reality. The result would be a few years in which the spec was out of touch with real use, before admitting defeat and accepting back in again. That doesn’t sound helpful for the cause of standards-compliance in general.”

    It does not at the moment apart from provide a styling hook. You can do the same as hgroup currently does with a div and that doesn’t remove the semantics for assistive technology users.
    The main purpose of hgroup is to mask heading semantics of subheadings from the HTML5 outline algorithm, the algroithm has not been implemented. The only implementation in browsers is that they recognise hgroup as an element for styling purposes. It has no accessibility support and the ‘support’ that is specced in HTML5 will simply collapse all headings in a hgroup into 1 heading.
    People writing in books about it is not a reason to keep it in the spec.
    The HTML5 spec is still in development, so early adopters should be aware that.

  • graham says:


    That’s a fair point and I understand your reasons around accessibility but, IMO, I think it’s interesting seeing how the spec (as unfinished as it is) is used and interpreted.

    Don’t forget about paving the cowpaths – if people are using hgroup to “provide a styling hook” but the outline algorithm isn’t being used then why is it wrong to keep in? Sure, you could use a div for this, call it <div class=”hgroup”> or whatever but – in the spirit of HTML5 – as with header and footer I don’t see what’s wrong with keeping it as it’s own element.

    Sure, early adopters of the spec will see meanings change or things disappear completely but we developers have waited sooo long for this and it’s clear people are keen to start using it. Of course some people will misinterpret or get it a little wrong along the way but that’s the fun of web development and an important way of learning.

    Taking a look at the first two pages of the HTML5 gallery, 7 out of 20 sites are using it on their homepage (as well as this site).

    Surely it’s more important to get the whole spec defined and push for it’s implementation instead of calling for removal of something because parts haven’t been implemented yet..?

  • When an element such as “hgroup” has been in the specs for more than two years, and is already being used correctly on a number of sites, and is being covered in several HTML5 books, then a very clear and strong case indeed is needed if it should be removed. I don’t see any such clear and strong case for a removal, and only very vague arguments. Furthermore the alternative solution must be convincingly and clearly better than the removed element. Every proposed alternative that I have seen seems at best not much worse than “hgroup”. None is clearly and convincingly better.

    Although “hgroup” might not be a perfect solution, it’s not that bad, and nothing much better has yet been proposed. So, in my opinion, “hgroup” should be kept.

  • adrian says:

    A subtitle is part of a title. It’s not a separate thing, and it’s not a second title. IMO, wraping <hgroup> (or whatever you want to call it) is nonsemantic and unintuitive. The whole point of semantics is to create a cleaner DOM, right? Most authors that currently use <H1> <H2> <H4> <p> whatever structure are unlikely to to wrap those Hns in an <hgroup>, or anything else. The current hgroup element only creates more confusion around the issue for webmasters who are trying to do things “right.”

    A subtitle is supplementary to the title, and therefore may not always need to be displayed – it’s not a critical part of the title. Other than that, a subtitle is wholly a part of its title. The only practical difference is that it is usually styled differently.

    My vote is for <Hn>Title <Hsub>subtitle</Hsub></Hn>.

  • adrian says:

    as an aside, I agree that the way the decision to remove <hgroup> was made was quite arbitrary. I do think it should be gone, though.

  • “as an aside, I agree that the way the decision to remove was made was quite arbitrary. “

    Its removal was due to the HTML5 editor playing games.

  • Lars Gunther says:

    Since I filed the bug in question perhaps people would like to know why I did it. To be clear, I filed it only and have not had time to drive the issue like Steve Faulkner has.

    A lot of comments here use the word like. And that’s the problem. There has been no research. People who have been involved with the process or read a few bokks have been introduced to hgroup, and perhaps think to themselves I can use that, but it has never been scientifically evaluated.

    I did provide some research about the teachability of hgroup to students who had no previous exposure, and the conclusion was evident. Having elements change meaning depending on them being placed within another element or not is a bad idea. Having a separate element for subtitles was far easier to grasp.

    There are also technical problems with hgroup. It is no backwards compatible. Existing AT technology will not realize that some headings in fact are taglines. It is also harder to parse properly for an outliner done in JavaScript or some other server side language, compared to using sub-elements within the header or having a subheading element directly after the heading.

    Some authors have indeed put out pages on the web that use hgroup, but except for the feeling of being cutting edge, they have received absolutely no technical benefit from doing so. No single browser implements hgroup in any reasonable way. The only thing Webkit does is to provide some default styling and make it part of the DOM.

    In fact, it was Webkit’s lame half-hearted implementation that started my thought process. The purpose of hgroup is not to add as a hook for CSS, but to actually hide the subtitle from the outline algorithm. Let me repeat: Not one single browser on the market is doing that today.

    Thus, there is no benefit whatsoever in using hgroup today. It is only done in the hope of there being a benefit in some distant future that no single browser vendor has pledged commitment to. The Webkit developers told me directly that they had no plans whatsoever to do anything more by way of supporting hgroup.

    The fact that some so called support tables lets Webkit based browser score a point for the sa called hgroup support is nothing more than a tragic misunderstanding. The semantics of the element is ignored.

    Thus, withdrawing hgroup is close to a zero cost proposal. No content on the web will suffer and browser vendors can fix whatever they need to fix in a few minutes of programming time.

    Until real proper scientific research has been done and findings have been provided, so that this discussion can move away from what we like or not, the most sensible thing to do is to remove hgroup from the specs – both the W3C and the WhatWG version.

  • @bertil
    you wrote
    “I don’t see any such clear and strong case for a removal, and only very vague arguments. Furthermore the alternative solution must be convincingly and clearly better than the removed element. Every proposed alternative that I have seen seems at best not much worse than “hgroup”. None is clearly and convincingly better. “

    As you feel so strongly, I encourage you to join the W3C HTML WG and help develop HTML.

  • Alohci says:

    Tab Atkins is the one one I’ve seen provide a clear use case for hgroup. He said:

    <hgroup> is a useful element that solves a real problem (that of
    accurately marking up and styling subheadings), and I support its
    inclusion in the language.

    It’s far from clear to me that hgroup is the optimum way of solving that use case.

    If the objective is to mark-up a subheading, then mint an element called “subheading” (or equivalent) and you’re done. Make it either a child or adjacent sibling of the primary header element, which-ever is easier to style. Having a container element that subtly changes the semantics of its child elements is simply not a intuitive way of doing things, and I’m not at all surprised that Lars and Bruce, who have actually tried to explain the element, have found that their listeners have struggled to “get it”

    <hgroup> strikes me as a programmer’s solution to the use case, and broadly speaking, only those with a programmer’s mind set are likely to grasp how to use it properly. Such people are the norm at the W3C and WHATWG and for that matter, here, but overall, represent a tiny fraction of web authors.

    Lars is right. He and Bruce are the only ones to have provided anything even resembling data, and that data is clearly opposed to hgroup. It would be nice to see the advocates of hgroup provide data demonstrating that it is the best way to meet the use case.

  • Alohci says:

    s/one one/only one

    I thought the adding the cite attribute to the blockquote might have resulted in the link being reflected in the rendered post somehow, but it seems not.

    Tab Atkins’s quote comes from

  • @steve faulkner:

    As you feel so strongly, I encourage you to join the W3C HTML WG and help develop HTML.

    I’ve just applied for an account. Thanks for the encouragement!

  • It’s not semantic in HTML5 but I’ve always been fond of:

    <h1>Heading <small>sub</small></h1>

    Perhaps would be more appropriate?

  • Oops, forgot to escape the HTML. I meant:

    Perhaps <sub> would be more appropriate than small?

  • @bertil
    “I’ve just applied for an account. Thanks for the encouragement!!

    no problem

  • Lars Gunther says:


    Neither small nor sub fit the bill. They already have a defined meaning that is not compatible, thus they have the same semantic problem that hgroup has – an element is redefined depending on its position.

    We will need a new element, but I just do not think there is clear evidence that hgroup is it.

  • adrian says:

    Its removal was due to the HTML5 editor playing games.

    good game. it got people to talk about it more. : )


    My main issue with <hgroup> being the new element is that it wraps the titles, where an element that helps define a subtitle should be one that is wrapped by the title.

  • Marcus Downing says:

    I disagree that the subtitle is part of the title. Consider a few real cases where a subtitle is used, such as this random example:

    Fears for euro in Greece prompt secret talks
    Europe’s inner circle meet to discuss possible debt restructuring for Greece as well as problems in Ireland and Portugal

    The first title is a self-contained object; the subtitle is an explanatory addition to it. If one were to merge the subtitle, as would be an implied result of placing it within the title, it simply doesn’t make sense:

    Fears for euro in Greece prompt secret talks Europe’s inner circle meet to discuss possible debt restructuring for Greece as well as problems in Ireland and Portugal

    I also believe it’s a mistake to assume that the contents of an <hgroup> would always consist of exactly two titles. Consider this example:

    AV referendum: Yes campaign handed thumping defeat
    Lib Dems wounded as UK votes to maintain first-past-the-post
    No campaign establishes unassailable lead of 69% to 31%

    It has a primary title and two explanatory titles, something that confounds some of the alternative markups suggested. This flexible grouping of all possible title-like fields is what <hgroup> seems a good fit for.

    Also, I must confess, it is a very useful hook on which to hang CSS.

  • @Lars Gunther:

    We will need a new element, but I just do not think there is clear evidence that hgroup is it.

    You’re probably right, but, since “hgroup” is already in HTML5, and has been there for more than two years, and is already in practical use, and has already been taught to thousands of developers, we need very clear evidence that is is not the right solution, and very clear evidence that something else that will replace it, is indeed the right way to go and is much much better thatn “hgroup”, in order to remove “hgroup” from HTML5.

  • Lars Gunther says:


    (That sounds Swedish, may I say “hej”?)

    A few notes. hgroup is not “in” anything but a draft. HTML5 has not reached CR-status and this individual item has not been explicitly called out as stable. It was put in the draft and basically neglected by most, since it’s such a small detail. It simply slipped under the radar.

    (BTW, I’ve been subscribed to the WhatWG list since 2006 and the HTML5 WG list since 2007)

    Neither is hgroup in “practical use”, since as I’ve explained above, no browser is actually doing anything useful with the element. All usage today is merely symbolic.

    What we do need clear evidence about is this:

    1. There is a use case strong enough to warrant the inclusion of any element in HTML. I.e. this is a common need.

    2. Careful analysis about the practical implementability of all proposed ideas. As I’ve said, the fact that Webkit really got it wrong got me started. Their so called implementation is an argument against hgroup. Not the other way around.

    3. Scientific research about the teachability of various propsals and to what extent they might lead to abuse or ambiguous situations.

    4. Scientific research about the way this element or any other propsal will be handled by WYSIWYG tools. (Those won’t go away.)

    What if a tool puts more than the heading and tagline within hgroup? What will the DOM look like? What should be the validator error?

    Again, I’ve seen no research, just opinion.

    Adding stuff because its been added – that’s the gist of your argument – is not compelling. Of course we will see some confusion when people buy (and perhaps write) books in the mistaken notion that HTML5 is a stable standard. But catering to that is a temporary problem. Writing a bad spec and let it reach a stable state will be an undoable mistake.

    In fact, that means that the burden of proof does not rest with people like me calling for a temporary withdrawal of the element, but on everyone who would like to see hgroup included. They are arguing for the risky path, I am arguing for the zero risk path.

    The sooner it is withdrawn from the spec, the better, since that will lessen any confusion. And if indeed hgroup is found to be the best solution, it’s easy to put it back.

  • @Lars : your bug report also uses the word like

    Is the lack of marking up subtitles/taglines in HTML 4 such a big problem, that
    we should at this stage introduce a solution – any solution – that clearly is
    not really liked?

    That’s doesn’t sound like a compelling reason to raise a bug. It’s certainly not a compelling reason to have the element removed from the spec in this way, at this stage…hence the revert.

    The idea that hgroup requires “scientific evaluation” seems to be holding it to a higher standard than any other HTML5 element. Where is the the scientific research that has informed every other decision in the spec?

    Hopefully any future decision to remove it from the spec will be done with proper discussion and the proposal of a viable, robust alternative (if any).

  • Lars Gunther says:

    The bug report was preceded by a discussion on the mailing list. It was a natural conclusion from that discussion. If there had been agreement there had been no bug. Hence the word “like” in its opening paragraph.

    The idea of “scientific evaluation” is not uniquely mine, but specifically argued by Ian Hickson. He (and others) have repeatedly asked for facts and numbers.

    Such a call is IMO the best way to settle an argument, provided the research is OK according to scientific standards: Reproducable, internally consistent, etc.

    There has in fact been much research done concerning various parts of the spec. Much of this happens when a browser vendor is doing the first experimental work on a feature. That has led to many spec changes and a few proposed elements, that had been part of the spec at least as long as hgroup, have been dropped.

    Thus dropping hgroup is not dramatic or extraordinary in any way. Just another day at work for the HTML5 process.

    As for discussion of alternatives, there has been quite a few such discussions. Some of which pre-date my bug and was part of the process that triggered it. But we do need more, on that I agree.

    Perhaps we should use hgroup, perhaps we should use an alternative solution, perhaps the use case is not sufficient enough to warrant the use of any dedicated element, but could be solved by a microformat?

    We simply do not know. The wise thing to do is thus not to keep it based on what “stage” we are in, but to drop it and investigate. But the supporters of hgroup are not investigating, AFAIK. Thus, we are stuck in a pseudo-discussion about procedure.

  • @Lars I think you’ve got “scientific research” confused with anecdotal evidence. Don’t get me wrong, anecdotal evidence is great and very useful, but it’s not “scientific”. Speaking of such, I’ve personally found teaching people about <hgroup> to be no problem. I suspect this is because I started with visual examples of <hgroup> usage rather than discussing how “it’s a requirement of the outline algorithm”.

    So since I’ve had a different experience, what happens now? Do our anecdotes get to wrassle for the title of most researchy? ;)

  • Andy Marshall says:

    I would likely take a tack of:


    …but then I had no particular beef with hgroup in the first place.

  • Andy Marshall says:

    …by which I (hopefully) mean:

    <h1>Title goes here</h1>
    <aside>Subtitle of article</aside>

  • @Lars : I think empirical data is important. But the spec hasn’t been developed using the ‘scientific method’…nor should it be.

    As for actual research, I thought the hgroup element was proposed as a result of an exploration of existing patterns. Lachlan Hunt has started documenting existing patterns in the WHATWG wiki as part of this renewed discussion. A larger collection of examples should help move things forward.

    I started investigating the real world usage practices for marking up subtitles
    and tag lines. From the pages collected so far, there seems to be a tendency
    towards using h1/h2 and h1/p elements for these purposes. Some examples are
    surprisingly close in structure to the design of the hgroup element.

    If you find more examples of real world usage, please feel free to add them.

  • Lars Gunther says:


    How come you think that I’m talking about anecdotal evidence when I am referring to scientific principles?

    I’d like to think that I’m very well aware of the differences. Do I have to provide footnotes to every single occurrence of what I’m talking about? If so, sorry, but I’m talking from my memory of things presented on the lists (WhatWG and HTML5) and i frankly do not have the time to dig through it all.

    As for your anecdotal evidence: Have you tried teaching different solutions in a neutral fashion to groups that have no previous exposure to the subject? I have – tried! And although my setting was not completely according to science in its setup, it comes a lot closer than what anyone else has done (AFAIK).

    My result? hgroup was not the winner, but no alternate solution stood out clearly either. Thus my conclusion was that more research is needed.

    Why are so many people prepared to take the path of greater risk even though their is very little

    In addition to what I’ve been trying to do with teachability, would someone please investigate the following:

    A. Writing an outlining algorithm – such as generating TOC – for various proposals? Which was the simplest, least CPU intensive and/or least fragile?

    B. Getting the different proposals to gracefully degrade, including support for existing AT users? (How did you hide the subtitle using hgroup….?)

    C. Implementing the various proposals in a WYSIWYG tool like CK Editor or Tiny MCE? (My guess is that it would be way more intuitive for an author to mark some text and click “subtitle” and have the program logic set that as an element, instead of trying to do some weird wrapping.)


    I can not for the life of me see why we should keep hgroup until this research has been done, because it might turn out to be the best solution.

    If we do not drop hgroup now, we will be in a position when it can not be dropped even if real world usage starts to show that it is a bad idea. Why would anyone in his or her right state of mind consider that path to be the best one?

  • Lars Gunther says:

    s/”Why are so many people prepared to take the path of greater risk even though their is very little “/””

  • George Katsanos says:

    I read all the HTML5 alternatives/solutions and seems by far more intuitive, simpler and easier to understand.

    I do not see any obvious reason to remove it from the spec.

  • George Katsanos says:


    I read all the HTML5doctor alternatives/solutions and hgroup seems by far more intuitive, simpler and easier to understand.
    I do not see any obvious reason to remove it from the spec

  • Alohci says:

    @Nicolas Gallagher – It amuses me that the only example of actual use of hgroup on the wiki page – the one from the apple page – uses it wrongly.

    This, to me, would represent the best data we could get. Given that hgroup has been around for a while, it ought to be possible to search for real world usage and see whether it’s being used correctly. Given that the current authors using the element ought to be far more clued up than the average web author, the percentage of correct usage should be high. It would be great to find out it that was actually the case.

  • @george

    I really see nothing intuitive about an element that when appplied:

    turns the above into:


    for assistive technology users:

    whereas something like this:



    <h2 subheading>subtitle</h2>

    conveys a clear role for the subtitle.

  • Marcus Downing says:

    But if you take this:

    <h2 subheading>subtitle</h2>

    And feed it to a browser/agent that doesn’t know the “subheading” attribute, or through an HTML sanitizer that doesn’t allow that attribute, or you just happen to typo it, you end up with this:


    in which the h2 introduces a section within the h1. That doesn’t clearly convey the relationship between the title and subtitle. If you look at the list of h2s at this level, you then have to divide the list into two parts: real h2s, and this fake h2 which isn’t really the same thing. Anything that produces the document outline, anything which assumes h2 at that level means something but isn’t careful enough to check, is going to be fooled by this. Using <h2> at this level seems simple enough to human eyes, but will lead to confusion in the technology.

  • @marcus

    But if you take this:


    And feed it to a browser/agent that doesn’t know the “hgroup” element, or through an HTML sanitizer that doesn’t allow that element, or you just happen to typo it, you end up with this:



  • Cent says:

    The name ist wrong – hgroup suggest its content is a group of headings, when in fact its content will be reduced to one heading, all other headings will be transformed to subtitles or such things.

    hgroup is for masking headings so it should be named hmask or something like that. Sure, that sounds advanced and complicated, since some authors have very little knowledge about masking in computing at all, but those authors will simply not use hmask while the advanced authors would have the choice to use it.

  • Pedro Plowman says:

    The problem for a lot of us poor bastards out in in production-land is that of moving targets and what I’ve come to call YAFTTL (Yet Another * Thing To Learn). Applying the mediocrity principle to myself in this context suggests that I’m not alone with my frustrations.

    Since I’m working on a greenfield project I decided on a forward looking approach, doing it all in HTML5, using those elements that I understand to be widely supported by browsers and being ready to use others as they are supported. The prospect of changes to the HTML5 spec that will affect what I’ve already laid down is a right PITA.

    If <hgroup> is to be removed from the HTML5 spec then my idea of a best alternative would be a small number of attributes on <p> to be used within the <header> element. I suggest subtitle, tagline (and I suggest both because others may see a bigger difference than I do) and authorship as the starting core. Using those we might end up with markup like this…

    <h1>My Great HTML5 Page</h1>
    <p tagline>Whooping it up in HTML5!</p>
    <p authorship>Pedro Plowman</p>

    Except for the necessary changes to my existing codebase that works for me.

  • Shauna says:

    Personally, I like Steve’s suggestion of having a <subtitle> tag. Perhaps the “for=” attribute could be available to use on it to make it even more clear that the subtitle is for a given title/heading?

    You could then attach any number of <subtitle> elements to a given title (similar to how you can have multiple <dd> elements per <dt>) without the context issues cited above. It should also be easily teachable, and AT can simply ignore it or even be set up to react in custom ways to it.

    The same could be said for something like an <author> tag.

  • I think this is going to be one of those “damned if you do, damned if you don’t”. I can understand people wanting a subtitle and Andy Marshall’s suggestions of a tag seems like a clear winner to me.

    I know some people will want multiple subtitles and again thats going ot raise the issue of how they are entered and how they are displayed. Why not simple have incremental subtitles like the good old h1, h2 etc?

    Stick it in a hgroup if you want, but I can’t really see a reason for it, it just seems like its been put in there for the sake of it.

    Then again there are a lot of people out there who know more than me, otherwise I’d be coming up with the new standards.

  • Lars Gunther says:

    I’ve given hgroup some more thought and from my horizon there also seem to be some technical problems, some of which I can’t remember having been discussed.

    1. It alters element semantics based on position for 5 elements (h1 is probably excluded…)

    Thus it effectively introduces five new tagline elements, along with hgroup, but they all re-use existing element names.

    Sooner or later this will become a burden for browser vendors and web developers.

    2. Hgroup does not degrade gracefully

    Among all of today’s browsers, as well as the browsers currently being developed, there is not one that is hiding the “subtitle” from the outline algorithm. Thus hgroup won’t work for real until at least 3 or 4 years into the future.

    Using it now will produce unintended document outlines and there is only one way of dealing with that: Substituting heading elements with other tags, having detected non-existing non-existing support.

    Which might be hard, since there is no way of doing such a test…

    But when one comes along, it would mean we’ll have to do something like this:

    if ( ! Modernizr.hgroup ) {
    var taglines =
    document.querySelectorAll("hgroup > match(h2,h3,h4,h5,h6)");
    for ( var i = 0, num = taglines.length; i < num; i++ ) {
    var content = taglines[i].innerHTML;
    var newelem = document.createElement("p");
    newelem.className = "tagline";
    taglines[i].parentNode.replaceChild(newelem, taglines[i]);

    And then author still will have to maintain duplicate code in their CSS and heaven forbid we’d like to do some DOM-manipulations, having to handle both the case of browser actually supporting hgroup and browsers in which the code above has been run.

    Which brings me to my next point.

    3. It breaks expectations when scripting

    getElementsByTagName(“h2”) will return taglines as well as real headings.

    I would suppose that few developers would appreciate the extra hassle of writing:

    querySelectorAll(":not(hgroup) > h2")

    That selector will also affect performance negatively. And it’s not supported by more than a few percent of today’s browsers, meaning we will have to use even slower algorithms to get the rest to tag along.

    And non JavaScript based tools will also be affected, so this problem is probably bigger than first meets the eye.

    Here is a $ 10,000 question: The current scripts that generates TOCs like the one at Modernizr, from existing documents, are those scripts hgroup safe?

    Unless they are, using hgroup will negatively affect developer expectations. There are probably lots of scripts floating around that will continue to see usage for quite some time.

    Thus, I restate my postion: Unless we are dead SURE that hgroup have no unintended bad side effects – and to me that seems very unlikely – we should temporarily remove hgroup from the spec.

  • David says:

    If hgroup is out, I’ll find myself using <div class="hgroup">, guaranteed.

  • Adam says:

    @David: So you use <hgroup> just because you have some heading followed by a subtitle and now a “new” semantic element appeared that seems to nicely wrap those, and moreover, you don’t have to use an additional ugly class in the markup to target it? (In fact you generally have to, unless you use CSS3 or something like: section>h2 to exclude non-subtitle headings). I think this is how many will think about it, but the reason why the element was added – to hide subordinate titles from the outline – will be easily overlooked.
    HTML designers are always so happy to welcome any new reasonable semantic element so the markup looks more attractive than a bunch of <div>s and <span>s and now when they have one such, even half-baked, they are not willing to surrender it. Lars Gunther’s arguments speak for themselves and as long as HTML5 is still a draft, it seems perfectly fine to me to take the path of the most appropriate and comprehensible solution as possible, in particular, after the experience with XHTML and it’s acceptance.
    Let me contribute with some suggestion on this issue. As the least problematic I found a modified version of <hgroup> which allows more elements to be used as its content, at least restricted to the non-sectioning content. Actually, I don’t understand why <hgroup> is currently restricted to the heading content only, forcing the authors not to put e.g. <p> inside. But real cases show that it could be useful to be able to decide whether heading, paragraph or small list (as in the last example posted by Marcus Downing) should be marked as a subtitle(s) and at the same time preserving the control over what will be shown in the outline. Just wrapping the “subtitle content” in the same manner as wrapping the footer content in the <footer>. Backwards compatibility and performance will not be affected. Compared to the actual spec of <hgroup>, there is a little disadvantage (as far as I’m aware) in my suggestion that is the a rank can’t be assigned to multi-level subtitles, but I think there is no need for such a luxury as the subtitles are very short, are read as a whole and thus no navigation between them is necessary. On the other hand there is an advantage of a possibility to put the “subtitle content” everywhere around the heading they are related to, so there is more room for creativity.

    let me introduce...
    The new sophisticated heading of this imaginary article
    ..I know, not so special indeed

    Posted by: ...
    Created: ...

  • Adam says:

    Oh, I thought <code> doesn’t need &lt; and &gt;..

    <p>let me introduce...</p>
    <h2>The new sophisticated heading of this imaginary article</h2>
    <p>..I know, not so special indeed</p>
    <p>Posted by: ...</p>
    <p>Created: ...</p>

  • DiegoV says:

    I was hoping the hierarchy of headlines would be more implicit in HTML5, especially since the new structural elements are so awesomely recursive. To me, it would be far better if we could lose the concept of numbering <h> tags and allow structure to determine hierarchy. With that purpose in mind, I’m in favor of adopting the more semantic <title> and <subtitle> tags… and let <h#> fade into obsolescence.

  • Adam says:

    @DiegoV: I agree, that was an alternative I have also considered – to structure the document using the sectioning content so the sections are made explicit and the scope of <subtitle>, when placed within them, would be clear. But I have picked the modified <hgroup> solution as it converges better with the current state. However, <subtitle>, in contrast, could be placed everywhere inside the section (the question is if that is necessary and logical), also an element which purpose follows its name is far more pleasant.

  • Shauna says:

    @Diego V – The <h#> comes from document structure (go figure). If you recall back to your college or high school days, when you had to write according to MLA or APA standards, you had heading hierarchies. First order headings have to be in all caps and centered, second order headings are left-aligned and title capped, third order are on the same line as the paragraph, etc. That’s actually what the <h#> tags are supposed to be for, not using an <h2> as a subtitle for <h1>.

    Without the <h#> tags, how do you propose we determine if a heading (subsection) is part of a higher-order heading (chapter; particularly programmatically speaking, since the markup itself is really largely there for the computers, styling it with CSS is for the humans), if not with the <h#> tags?

    Now, I agree, I would love to see the misuse of <h#> be replaced by something better suited to including a subheading in markup. Maybe <hgroup> will be that alternative, and maybe <h#> will end up more like <table> – not used nearly as much as it used to be, but also not abused like it used to be; but to wish it into obsoleteness misses the real intention and purpose of the tag, I think.

  • DiegoV says:

    The problem is that <h#> imposes an order outside of it’s relationship within the document. In outlines, it’s not the alpha-numerals that give the hierarchical structure, as indention alone would suffice. It’s the same for markup, contextual inference should be enough. Consider this as a possibility:


    Numeration is unnecessary. And if I understand the <hgroup> argument correctly, the need is to associate subheads with headlines without the numbers messing up the hierarchy. The numbers, therefore the tag, should be deprecated.

    But as far as subheads are concerned, there have been plenty of viable solutions mentioned earlier it the thread. Even nesting appeals:


    We should strive for simplicity and fewer tags.

  • Adam says:

    We should, and maybe in the future we will enjoy such a simplicity (or maybe some more far-sighted civilizations in the outer space already enjoy now :-), but this is actually out of the topic about <hgroup>. Backwards compatibility must be considered here, so the presence of <h#> is still here to make the transition easier.

    Nesting a subtitle inside a heading element still expose the subtitle to the outlining algorithm, which I admit may be desired in some cases, so the solution should be as most universal as possible.

  • Shauna says:

    @Diego – You only go two deep. How would add a third or fourth level to that? And how would you style it? (I have my own ideas, but as you’re the one that wants to get rid of <h#>, I’m interested in your solution.)

    <h#> only really imposes order outside of structure because that’s how current browsers render it. Just like the meaning of <b> has changed with HTML5, so can <h#> be changed to provide a meaning more in line with today’s ideals.

  • Jonathan says:

    Either allow <hgroup> to support elements beside <hX>, or introduce a similar element that will, like <subline>.

  • Join the discussion.

    Some HTML is ok

    You can use these tags:
    <a href="" title="">
    <abbr title="">
    <blockquote cite="">
    <del datetime="">
    <q cite="">

    You can also use <code>, and remember to use &lt; and &gt; for brackets.