On the hgroup element
The more I try to explain it to people at workshops and in a marvellous book, the more uncomfortable I become with <hgroup>.
In the spec, it’s defined
The hgroup element is typically used to group a set of one or more h1-h6 elements to group, for example, a section title and an accompanying subtitle.
It has no rendering; its sole purpose is to hide subtitles from the outlining algorithm which browsers, third party sites (warning:broken) or bookmarklets may use to make document outlines/ tables of contents.
So if you have the following code
<header>
<hgroup>
<h1>bruceawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
</hgroup>
</header>
only the <h1> appears in the outline; the <h2> is suppressed. (The highest-ranking heading wins.) More on <hgroup> at HTML5Doctor.
The trouble with this is that there is a new magic element that does nothing except change the semantics of its contents in a way that is new (there has never been an outlining algorithm before) so it’s difficult to grasp.
There was discussion about minting a new <subtitle> or <tagline> element instead. This has the advantage that it”s much easier to grasp the purpose of it. However, these new elements would have no default rendering in legacy user agents and, the argument against continues, people are already marking up subtitles as headings, so this way paves a cowpath. (I have my doubts: I usually encounter constructions like <p class=tagline>Gorgeousness in a gimp mask</p> for subtitles).
Thinking out loud here, but I wonder if we need explicitly to group headings and subtitles, anyway. It seems to me that an outlining algorithm should just treat multiple headings (<h1>…<h6>) that are direct children of a header element to be a group of “main heading” and subtitle(s) automatically. So
<header>
<h1>brucelawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
</header>
would automatically “know” that the <h2> is the subtitle and not be shown in an outlining application.
This would only work for direct heading children of a <header>: here’s an example of multiple heading descendants in which the <h3> is not a subtitle:
<header>
<h1>brucelawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
<nav>
<h3>Main navigation</h3>
<a href="home.html">Home</a>
<a href="about.html">About</a>
</nav>
</header>
I can’t think of any use cases for multiple headings as children of a <header> that wouldn’t be main heading + subtitles.
Can you?
(Also: ambiguities in mapping <hgroup> and ARIA information.)
Added later, after coffee: The outlining algo would only need to say: adjacent headings in a <header> are automatically considered to be a heading and subtitles, whether there be 2 or 22. Then, even if there were two headings for the <nav> inside the <header>, they would be automagically heading and subtitle.
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
41 Responses to “ On the hgroup element ”
Yay… Small print to tiny to read at this time of the night. Example now escaped:
<section>
<header>The brokeback mountain incident:</header>
<hgroup>
<h1>Bruce Lawson is king!</h1>
<h1>Gorgeousness in a gimp mask</h1>
</hgroup>
<p>Lets pimp HTML5</p>
</section>
Now; find my bed…
[…] RT @brucel: Some (incomplete) thoughts on #html5 <hgroup> http://www.brucelawson.co.uk/2010/on-the-hgroup-element/ […]
**sigh**
The W3C was never wrong about XML and XHTML. We should all be using that now instead of this silliness. But the script kiddies have taken over and we’re stuck with it to the detriment of all.
May the punishments we are to receive for all this not be too harsh.
I can certainly understand the necessity behind the proposal of this element, however I agree that there could be a cleaner and less verbose approach. I’ve been using it for a bit on a few “bloggy” designs but it always feels a kind of wonky to me.
Personally, I like the idea of a subtitle/tagline tag instead. But, then again, having an extra semantic wrapper like hgroup could be useful given certain design contexts. I’m kind of on the fence about this one. Thanks for sharing your thoughts as always.
The problem I’ve always had with hgroup is the idea that “taglines” are headings. They are not. That’s why most people mark them up as paragraphs with a class.
What is the point of having a h2 followed by no content except a h3, and then having to have all the following content drop to h4’s? “Gorgeousness in a gimp mask” simply isn’t a heading – it has no relation to the following content. It’s not a container for the following content. It’s just a linguistic decorative flourish.
I also dislike the idea that there’s an element added specifically to _remove_ semantics from the mark up. If we want an element that doesn’t have semantics we already have the option of a div or a span. Why on earth would we want to mark up an element as being one thing and then say “no not really”?
Messy, confusing, un-needed, and ill thought out, stemming from a poor interpritation of “paving the cowpaths” where people are simply using semantics incorrectly if that’s the way they go about taglines.
Hiya Bruce,
Interesting post, I have to say I agree! The general conses I hear from other developer is that hgroup makes a heading it own semantic block… Therefore I keep coming across page marked up using a h1 surrounded by a hgroup. Outlining is useful but it’s most useful for users of assitive tech, it does seem to have been made more complicated than it really needs to be IMHO.
Cheers,
Jamie & Lion
Subsequently: the above reasoning is why I never will use hgroup.
Yes, the hgroup is a little redundant. Now is only good for the outline, but I guess at some point the new HTML5 elements will have some default style, maybe later the becomes more useful.
If hgroup didn’t suppress things from the outline algorithm, would we use it? I certainly might as a stylistic hook. I can imagine a use case for saying the hgroup gets a certain font with certain attributes in the CSS.
It seems to me the current hgroup implementation isn’t terribly useful. Can we get the meaning changed or do away with it all together?
This type of approach makes too many assumptions.
like Matt W, The only issue I see here is that ‘h’ tags are headings (not subtitles); and no tag should have its semantics changed because of context.
Context is very powerful and this sounds like a slippery slop to me. or
I usually mark up these taglines using the <small> element. I see the tagline or subtitle as a “smaller” part of the main title, that usually clarifies or explains this title. It’s not another heading, but a part of the same heading that could be considered as “additional”.
Additionally, you can style it as a block to put it under the title, or you can keep it smaller on the right side; you can even use a small “pre-title”, that is very common in news articles.
And, at least for me, it is completely semantic if you abandon the assumption that “small” only means “small size”, but “less important content”. And it is backwards-compatible, too! 😉
Very interesting post, thanks! 😉
I don’t know if hgroup is the best possible solution, but I often use h2 immediately after an h1 where it is not a tagline. I see that in other peoples work as well.
I agree with you for the most part. As I’ve taught HTML5, I’ve been less and less comfortable with it for similar reasons.
Yes, some devs use h1/h2 for title/subtitle. But in truth, why do we do that? It’s usually styling reasons that cause us to use a second heading—which is never a good reason. I agree that in most cases, either a P element with a class or using the B element around either the title or subtitle within your original H1 (and setting it to display:block while adding different styling) will take care of most people’s needs. (Remember, the B element has been resurrected and repurposed for styling.)
I *can* actually think of a reason people may want to put their tagline into a heading however—SEO. If your tagline has good key words or key phrases in it, then there could be valid reasons outside styling for using a heading. But then the B element within your H1 would still take care of that.
I wouldn’t personally use the small element as the subtitle. Small has been redefined to be for “small print”—more like legalese, copyright, etc. Not to just visually make the element smaller.
I do think removing hgroup altogether, and then using your method of leaving the second heading out of the algorithm, is excellent. I’ve used hgroup in a couple of my HTML5 projects (’cause I was supposed to, ya know). But it just feels fairly pointless. I’ll probably go with the B element nested in a heading myself. 🙂
I think taglines can be headings in the context described by Matt where there’s a non-descriptive company name followed by a more descriptive sub-heading e.g.
Johnson Group
The World’s No. 1 Website Company
Is it really removing semantics, or just removing it from the outline the same way as sectioning root does?
Also, a section with an h1 immediately followed by an h2 that creates an implicit section is ok, so it would definitely need to say “only in header”.
Interesting Bruce,
Just to throw another option into the mix as opposed to your adjacent suggestion how about making use of the for attribute (query making for a global attribute)?
[header]
[h1 id=”title”]bruceawson.co.uk[/h1]
[p for=”title”]Gorgeousness in a gimp mask[/p]
[/header]
Not exactly perfect as you need an id on the h1 would mean the h1 & tagline don’t *have* to be next to each other.
I know this will display my ignorance worldwide- but WTF are on about?
Stephanie said:
“I wouldn’t personally use the small element as the subtitle. Small has been redefined to be for “small print”—more like legalese, copyright, etc. Not to just visually make the element smaller.”
Yes! I forgot that… I agree with the B argument, thanks 😉
The problem I’ve always had with hgroup is the idea that “taglines” are headings. They are not. That’s why most people mark them up as paragraphs with a class.
From Bruce’s original example:
<h1>bruceawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
<>This is the first sentence in the article that follows the heading.</p>
I don’t know about anyone else, but I don’t believe ‘Gorgeousness in a gimp mask’ and ‘This is the first sentence in the article that follows the heading’ have the same semantic weight so don’t believe they should both be wrapped in paragraph tags.
Proposal: rename and change <hgroup/&rt; into the famous, generic header element that we all want. E.g. call it <heading/&rt; or <h/&rt;. But keep <hgroup/&rt;‘s content model: allow it to take one or more <h[1-6]/&rt;.
Bruce, what do you think?
This would allow authors to write backward compatible code: just pop a <h[1-6]/&rt; element inside the generic heading element — same as for <hgroup/&rt;.
(Sorry, I repost due to the stupid coding typo:)
Proposal: rename and change <hgroup/> into the famous, generic header element that we all want. E.g. call it <heading/> or <h/>. But keep <hgroup/>‘s content model: allow it to take one or more <h[1-6]/>.
Bruce, what do you think?
This would allow authors to write backward compatible code: just pop a <h[1-6]/> element inside the generic heading element — same as for <hgroup/>.
Regarding <hgroup>, I have been wondering about what could be the correct way to markup the heading of a news article, as it generally has a stabilized pattern in newspapers:
—1: The kicker, a phrase that goes right before the heading, usually a short teaser or the name of a section. (e.g. “Economy ensues”)
—2: The headline (e. g. “Chávez changes the Venezuela currency to Chavodollars”)
—3: The drop deck, the paragraph that gives a short abstract of the article. (e.g. “The measure has been complied with skepticism by the more conservative people.”)
—4: The byline, the line that contains meta info like the author, his/her bio; and/or the date of the article. (e.g. “by Don Shank at 15.10.2008 | permalink”)
An approach that had been suggested to me:
<article>
<header>
<hgroup>
<h2>Kicker</h2>
<h1>Headline</h1>
</hgroup>
<p>Deck</p>
<p>Byline</p>
</header>
[...]
</article>
I think it was fine except for the byline. In blog posts is the zone that wraps the author, date and post tags, and may be dispersed at the header and footer of the article. Most of the time it is solved by using a different class, but the fact that it needs a different styling from the main content is precisely the reason it may need to be differentiated (many “bylines” inside and article may use different classes without problem). There are elements for that stuff like <small>, but that is inline and I think it should be a block, because some stuff may need to wrap lists. The <footer> element is much like that too, except for the fact it can’t be used inside the header, which in many times meta info appears.
I believe that a paragraph inside a header may be enough to tell is a drop deck or part of an abstract, thought it may not apply to all cases where several paragraph are used and languages like Latex has markup for it. I considered proposing a new element, but at this stage will be somewhat complicated.
The H2 inside an H1 serves as a kicker, but without hgroup won’t make much sense, and as a paragraph along the other paragraphs in the header may get semantically lost, I think.
Just my two cents, but I’m not even sure that omitting subtitles from the outlining algorithm is such a good idea in the first place. In a fair few cases they offer important context to go with the main title.
More cents: wouldn’t it be nicer to nest the h2-tag into the h1 tag to indicate a subtitle? Would be backwards compatible and the only thing needed would be to lift the nesting restrictions in the heading elements.
Meant to say earlier, the outliner at http://gsnedders.html5.org/outliner/ is working again.
@Bruce: The last example in the <header> section of the HTML5 spec has an example of the sort of situation in which you might have adjacent headings. Remove the <nav> block and you have <h1> followed by <h2> in the header with the second heading intended to create a new implicit section.
@Andrés: You could markup the information you describe like this:
<article>
<header>
<hgroup>
<h2>Kicker</h2>
<h1>Headline</h1>
</hgroup>
<p>Deck</p>
</header>
<footer>
<p>by Don Shank at <time pubdate datetime="...">15.10.2008</time> | permalink</p>
</footer>
[...]
</article>
@Andrés this are exactly the topic I want to address in my first comment to this post. Some of the therms you use are related to terms we use here in Norway, but we just use different words.
Here in Norway we have a tradition that what you call a “kicker” (we call it a running head) are a “header”. For us a “kicker” are a “header” describing a long lasting context or a series of articles the article belong too.
If I look away from the spec and just look at the tags provided, a natural semantic structure for us would be:
<article>
<header> Glastonbury Festival</header>
<hgroup>
<h1> Bruce rocked the crowd once again</h1>
<h2> True awesomeness! Will we ever be tired of this star?</h2>
</hgroup>
<p> Text of the article</p>
</article>
For us, this is very natural and rooted in a long journalistic semantic from long time before the Internet. For us, the hgroup plays an important role, but it lives outside the header because “header” has a different meaning for us. This might be “wrong” markup, but for us feels right because of long rooted terms and traditions of using these terms.
I think some of the new semantic tags in HTML5 in a way introduce some confusion due to different understanding of the words. I am particularly worried about the “header” and “article” tag.
An “article” in Norway are an news article in a newspaper or a magazine. Period. An “article” in the UK can also be referring to a DVD (probably one by Hurra Torpedo).
Bruce: ironically (or not), the dom remains pretty much the same in ie6-ie8. Opera doesn’t mind either (didn’t check 11 though).
It’s ie9, FF3.6 and both webkits that rearrange the dom, pulling the h2 out of the h1 again.
[…] – On the hgroup element “The more I try to explain it to people at workshops and in a marvellous book, the more […]
[…] There is some anecdotal evidence that the element is difficult for people to grasp — Bruce Lawson discussed it with developers and Lars Gunther experimented on students. There are a few bugs opened on it and Steven Faulkner is […]
I previously and repeatedly argued for hgroup to be renamed h, because with only text node children it basically works the same as the XHTML2 element of the same name. The grouping of h#s is just an additional benefit in my opinion.
Do you think a markup like this would work out? What do you think?
<h1>My grand title<subtitle\>My little subititle</subtitle></h1>
I thought it was useful to give semantic meaning where otherwise I’d have a div. I don’t use outlines, but:
<article class="job-listing" >
<hgroup title="click here to reveal more details">
<h1 >Website Refresh Manager</h1>
<h2>Engagement: <time datetime="2010-05-03">3 May 2010</time>–<time datetime="2011-01-14">14 January 2011</time></h2>
<p><strong>Location:</strong> <span>SolidWorks Corp.</span></p>
<p><strong>Contracting Group:</strong> <span>Eliassen Group</span></p>
</hgroup>
<div class="content">
seems a good use to me?
[…] shan’t be sad to see it go; in November 2010, I argued that it was too hard to grasp; if you want to indicate that something is a subtitle or tagline, you want to indicate that on the […]
[…] On the hgroup element […]
[…] On the hgroup element […]
[…] On the hgroup element […]
I kinda agree on your thought. Tough I see a use for hgroup outside of the header element. In news sites we sometimes have something called “running head” which are a “title” for a running series of stories.
In such a case I can see a need for putting the semantics like this:
The brokeback mountain incident:
Bruce Lawson is king!
Gorgeousness in a gimp mask
Lets pimp HTML5
Tough; I do not see why the h2 should be suppressed.