If you don’t already know, the
hgroup element is obsolete in HTML5.
Advice is now provided in the HTML spec on how to mark up subheadings, subtitles, alternative titles and taglines using existing and implemented HTML features.
Russian Translation of this article: Разметка для подзаголовков by Frontender magazine
Advice for marking up subheadings and the like
The important question for developers is: How do I mark up these buggers???
To answer this advice and requirements have been added to the HTML specification on how to mark up subheadings, subtitles, alternative titles and taglines:
h6elements must not be used to markup subheadings, subtitles, alternative titles and taglines unless intended to be the heading for a new section or subsection.
Note: Example below added 10/5/2013
In the following example the title and subtitles of a web page are grouped using a
headerelement. As the author does not want the subtitles to be included the table of contents and they are not intended to signify the start of a new section, they are marked up using
pelements. A sample CSS styled rendering of the title and subtitles is provided below the code example.<header> <h1>HTML 5.1 Nightly</h1> <p>A vocabulary and associated APIs for HTML and XHTML</p> <p>Editor's Draft 9 May 2013</p> </header>
In the following example the subtitle of a book is on the same line as the title separated by a colon.<h1>The Lord of the Rings: The Two Towers</h1>
In the following example part of an album title is included in a
spanelement, allowing it to be styled differently from the rest of the title.<h1>The Mothers <span>Fillmore East - June 1971</span> </h1>
In the following example the title and tagline for a news article are grouped using a
headerelement. The title is marked up using a
h2element and the tagline is in a
pelement.<header> <h2>3D films set for popularity slide </h2> <p>First drop in 3D box office projected for this year despite hotly tipped summer blockbusters, according to Fitch Ratings report</p> </header>
Note: Some have been advocating of the use of the
small element to signify subtitles. This has been under discussion in the HTML working group, but no compelling arguments for its use have been made. Therefore it is not advised to use
small to mark up subtitles.
What about the document outline?
If you want a subtitle to be displayed in the semi-mythical document outline, include it along with the heading text as per example 1 and 2 above. If you don’t, put the text in a
p element (for example), as per example 3 above.
Questions for developers
Does the advice in the spec cover the use cases you encounter? If not what other advice should the spec include? Are the examples clear and unambiguous? If not how could they be improved? Any other questions you have, ask away in the comments!
If you are really keen you can join the likes of Bruce Lawson, Ian Devlin and myself in the HTML working group and take part in discussion there.
What being obsolete in HTML5 means
must not be used by authors
hgroup like other obsolete features, is non-conforming. This means that a conformance checker displays an error if the
hgroup element is found. The following is the error message displayed by the W3C Markup Validation Service:
hgroupelement is obsolete. To mark up subheadings, consider either just putting the subheading into a
pelement after the
h6element containing the main heading, or else putting the subheading directly within the
h6element containing the main heading, but separated from the main heading by punctuation and/or within, for example, a
spanelement with differentiated styling. To group headings and subheadings, alternative titles, or taglines, consider using the
Like for other obsolete elements, browsers will continue their current level of support for
hgroup. That is, browsers that have parsing and user agent style support will continue to do so, therefore authors that have used
hgroup in their pages do not need to rush out and remove it. The element effectively has no meaning as its semantics have not been implemented. It’s effectively a
div with a funny name.
The whys and wherefores
Much has been discussed and written over the past few years on the
hgroup element and whether it meets the high bar required to include as a feature in HTML, on balance it has been decided it does not. Should this have happened more quickly? Yes , but as Mike[tm]Smith stated recently:
People disagree. Organizations disagree. The task of us all working together to try to overcome our disagreements is time-consuming, often very frustrating, and almost never easy.
If you want to read up on the history of
hgroup there is plenty of stuff available:
HTML working group mail archives 2010 (tip of the iceberg):
- suggestion for abolition of
hgroupand ARIA outline thread
- suggestion for abolition of
71 Responses on the article “How to mark up subheadings, subtitles, alternative titles and taglines”
Thanks Steve. The most common examples we run into are for News and Events.
We’ve been using the following for News:
Well, since my HTML got stripped, here’s a gist with the markup: https://gist.github.com/erunyon/5509414
Both are followed by the excerpt or content. Both would be contained in an “article”. Would your recommendation be to change the h2′s and h3′s to paragraphs?
The spec page that you link to saying not to use <h1>–<h6> elements for subtitles does that very thing itself!
yep, the spec code needs updating to reflect best practice. I am working on such things. For instance I have recently made improvements to the spec styles so that sufficient color contrast is provided between foreground and background colors. If you have any suggestions, feel free to file a bug
The markup options mentioned (1, 2, and 3) are the way I’ve been marking subtitles and subheadings and taglines since like forever, especially option 2 with the
spanelement, it kinda made a lot more sense to me than using
hgroupwhich I remember using only once ever since I started with HTML5.
agreed, when developing the advice to add to the spec I asked around and looked at common code patterns for marking up subtitles etc.
Is not using
<hi>elements like that ‘mere’ best practices, or is it actually a requirement?
I see it’s phrased as “Do not …”, which sounds like a requirement but it isn’t phrased in the “You must not …” language of requirements.
Either way, that phrasing is confusing.
Since the text does not use RFC terminology its not a conformance requirement, if you find it confusing, would be great if you filed a bug.
ok HTML got stripped off.. so here’s filling in the blanks:
“especially option 2 with the SPAN element”
“made a lot more sense to me than using HGROUP-tag which..”
Bah, I wrote the above as:
That is, I put the “i” in an
<i>element, to signify it being a variable, standing in for 1–6 (since the
<var>element isn’t in the allowed tags list at the left).
<hi>— it seems a bit sneaky to tell people commenting they can use certain elements, not offer a preview feature, and then remove use of those elements!
Sorry for the comment torment, the term ‘sneaky’ implies some malevolent intent which would most certainly be the work of Dr. Bruce Lawson.
hx use bug filed
Steve, thanks for clarifying, and for replying so speedily.
It’s confusing because it isn’t clear what the status is of a spec telling authors “do not do this, but it isn’t the case that you must not do it, nor even the case that you should not do it”.
If I do do it, so what? Nobody can complain that I’m not meeting the spec’s requirements.
Or if somebody did wish me to follow commands such as that, they could request that I write “valid HTML which complies with all ‘do not’ commands in the spec” — which as well as being unweidly, also de facto introduces a third level of conformance requirements.
If it’s really something that authors shouldn’t do, then make it a proper conformance requirement. If it’s OK for them to do it, don’t tell them not to do it.
If that makes sense to you and this is something you’re interested in fixing, feel free to copy my comment into a bug report, if that helps with the process.
Getting feedback and improving the spec is certainly my intent. I have filed a bug with your comments. Thanks!
You know, I’ve been thinking about
<hgroup>for a while, and it’s been bothering me — it seemed like a solution looking for a problem. It didn’t make sense to me that someone would want to use an
<h1>and then tell the document outliner that it’s not actually an
<h2>at all but a mere tagline. It seemed like using HTML in a presentational, rather than semantic, way. Good to see that it’s been struck out. The
<header>pattern is much more meaningful, in my opinion.
But are the above codes compatible for search engines?
From a reading of the Google Search Engine Optimization Starter Guide (PDF). I can find nothing that indicates the above patterns are incompatible with search engines. I did note an interesting statement in the guide:
Adding markup simply to style it differently? You may want to rephrase that. Regardless if you wish to style it differently or not, you should have the markup reflect the semantics of the content.
I personally think that if we already have something like `figure` and `figcaption`, introducing ‘hcaption’ would fit well into that pattern.
The markup does reflect the semantics of the content, its a heading which may be displayed on multiple lines or on a single line and I want to include the whole heading text in the ‘outline’. For the example I used
display: blockto create the desired display effect as it provides a line break in browsers that support it. An author could use a
<br>element if a new line was all that was required.
Or an author could use character such as
-if the delineation between the two parts of the title are considered to be of importance, If the author wishes to modify the display dependent on device, a span could then be used to style the character as desired.
THE MOTHERS <span>-</span>
hgroupwasn’t exactly what was needed. Wouln’t it be a good idea to create a new element for that? For example:
<h1>The Lord of the Ring <sh>The Two Towers</sh></h1>. It seems to be the easiest and the best way:
shwould be phrasing content element and allowed only within
The element you describe is similar to one of the proposals that has been floated. What is needed is someone or some group of people with sufficient interest to move the proposal forward. A How To on going about doing this is available.
I’ll take a closer look as I finish current project, thx for info . The
hsubseems to be even more accurate tag name :)
Method #3 strikes me as the most appealing, personally. Something about span tags I’ve just never loved, and hgroup was baffling, once you used an hgroup say:
<h1]Hey I’m the Title</h1>
<h2]And I’m the Subtitle[</h2>
Would I then proceed to use <h3> to mark up sub-sections, or am I supposed to jump back up to <h3> and maybe using <section> or something?
I think method #3 will be implemented from here on out with my sites (until perhaps something better comes along).
Thanks for the insight!
What about using <strong> to mark up the main heading like so:
<h1><strong>CSS Secrets:</strong> 10 things you may not know about CSS</h1>
That’s what I used to do before <hgroup> and unlike <span>, it has some semantics that match usage (I think).
coincidentally I raised the same mark-up pattern yesterday on twitter and on the HTML working group mailing list. There is rough consensus that it is not a good idea to use
strongto explicitly signify a title, but of course it can be used in headings as per its usual semantics.
I’d be interested to hear your thoughts on the ‘semi-mythical’ outline: AFAIK it’s not yet implemented in browsers, but it should be (in the future), correct? I can see some value in the Outline and while I agree `hgroup` had its problems I do feel there’s a need for an element containing the ‘semantics’ of a subheading.
Most of the examples of current markup deal only with ‘styling’. As for examples 1 & 2: they _add_ a subheading to the main heading. In practice there is no structural and semantic difference between the two strings: they _are_ the main heading.
Using a `p` signifies it as a paragraph no? So there remains no way of marking up a subheading except styling.
In my mind Lea’s proposal of using `strong` is the only approach that attempts to add some semantic distinction (the other way around in this case).
Anyway, since in my mind the Outline remains to have some value (at least in the future) I can only think of adding a new element such as `byline` or `hsub`.
There are no requirements in the spec for browsers to implement in respect to the outline algorithm. There has been some discussion (IRC discussion between Mike[tm]Smith and Hixie) about the possibility of defining requirements, but there are no plans and no apparent browser implementer interest. There is one implementation of parts of the outline algorithm in a screen reader (JAWS) but it is buggy and word is that it will be removed. The outline algorithm is implemented in the W3C HTML Validator.
You are partially correct. In practice what does the semantic distinction imply, who is it meant for? who would make use of it? Is it of sufficient significance to require the use of an element? Example 1 uses a colon character to break up the heading into 2 parts, All users get access to this and can interpret it meaningfully, so there are semantics there. In example 2 there is a line break which again breaks the heading into 2 parts, of how much importance is it that one be marked as a subheading over the other?
take the following heading (images):
Both of them are semantically the same to me, but we could imbue some extra semantics to them based on the relative size of the bits of text and the order in which they are displayed, but what good does it do?
What are the semantics of p? how is it conveyed to users? Or header? how is it conveyed to users?
headergroups the the content and when that content is a
Hxand some other content, it says this stuff; the heading and this other content goes together. Why do we need more than that? We sometimes want to imbue magical semantic properties to HTML elements, often times they don’t exist and are of no practical benefit.
The spec itself solves this issue.
Mark the title with
<strong>, the subtitle with
bis the article lede.
I settled on using
<strong>Main Title<strong><b>Sub Title<b>.
It’s both semantic and allows me full styling control.
The above is of course wrapped within <h1></h1>
Steve, thanks for your quick reply. It seems the Outline is indeed even less relevant than I assumed :/
I’ll avoid discussing ‘semantics’ (here be dragons :-) but I agree they are of little value if they have no practical benefits.
The only other practical benefit of a separate subheading element I can then think of is that of SEO but then there might be better alternatives such as microdata (or not caring and focusing on people over robots ;).
I guess I’ll probably go with <h1>Main heading <b>subheading</b></h1>
<b/> is short, does not convey extra importance and the Spec indeed mentions it can be used as an article ‘lede’ (which is not exactly the same as a subheading, but close enough)
The Ramones would be (as you said – same semantics, different styling):
<h1>Hey! Ho! Let's go</h1>
But what about let’s say: W.A.S.P. – The Story of Jonathan (Prologue to the Crimson Idol).
<h1> The Story of Jonathan <hsub>(Prologue to the Crimson Idol).</hsub> </h1>
<hsub />would expand the basic meaning of
<h1 />as it is in logotypes for example.
But as I look at the BigBossSNK’s solution I’m not really sure (as always when it comes to digging deeper) if
<hsub />is necessary.
I’m only not fully convinced about using
<strong />within heading – I always felt strange doing that. Can’t find anything against it, but yet it feels strange – the
<strong />to me is or , but I’ve always been looking at a
h1-h6as elements with – maybe it’s my bad.
Sorry, span class in examples would be ‘artist’ and tabs messed up indentations.
A method to augment the semantics of HTML is to use metadata (RDFa or Microdata = choose your poison). Looking at the various schema on schema.org I found this under Creative Work:
As to the semantics argument, the document outline is your web page’s Table of Contents.
Suppose a blind readers want to find Chapter 7 in the HTML5 version of Lord of the Rings.
If Main titles and Sub titles are differentiated, he can skim through chapter names till the chapter he wants.
And, if he can’t remember what chapter he left the book in, he can read the Sub titles to each chapter, getting hints to each chapter’s content.
That’s the point. All the metadata (Microdata, Open Graph, Microformats etc.) is only augmenting the meaning (if I understand it correctly), but not giving it. And it should be done with the appropriate elements… which are missing. AFAIK HTML 5 specification was suppose to provide them, not change the existing ones like
betc., which was not so good idea IMHO.
I think the semantic web people may disagree with this. When you look at examples of Microformats, RDFa or Microdata markup, they often hang the semantics off
divelements, same goes for ARIA.
@Steve – of all the options <small> still looks the most sensible. I think we just need to tweak the spec definition of <small> slightly.
make it say
“lowered prominence” is what one would naturally expect of small print, but would also work for other situations such as taglines. It’s also natural, I believe, to think of a <small> tag lowering the prominence of its contents.
Microdata, as its name suggests, is about data instead of semantics. Microdata is used to make certain types of contents machine-extractable so agents like search engines can understand and use the contents easier.
The reason that authors of the examples of Microdata often use
spanmight be either they don’t know how to use right HTML elements for right contents or there is no proper HTML elements for those contents to use.
I really agree with Tom’s opinions that the meaning of a content should be given by appropriate HTML elements which in many cases are currently missing, and HTML5 was supposed to provide appropriate new elements instead of just altering the meanings of old elements such as
hmm, again I will say I believe the semantic web people would disagree with you.
There was a time when mentioning my work on the Internet was almost invariably met with the response “The Inter-what?”,
and then along came this little program named Mosiac supporting an element set that could be tallied up on one hand. At that point gopher was still the most useful.
It’s been fairly interesting watching the gyrations as the “Inter-what” has grown to be that integral part of business and culture world wide. It’s still but a young teenager as such things go, with the most amazing stories of it’s life yet to be told.
“The semantic web” , is a pretty catchy name for this particular round , and as always it will be with the attentive ear and eye the latest in grand ideas will be followed, with just the occasional comment such as maybe the select element might enjoy the datalist too or some such random thing.
It had been the better part of 20 years of coding before the “Inter-What” found it’s now adoring audience, and now it’s almost a like distance further since. It has to be my favorite and longest running reality show (at times just as realistic as such)
It will be a well watched season when the next cycle begins to see what of the new becomes wrote and which in it’s turn becomes depreciated.
@alohci, your change sounds reasonable, but others have voiced strong opinions about the use of small. Can i suggest you file a bug against the HTML spec and we can see where it goes from there?
I’m a bit surprised of the use of span (or other natively inline elements) for subtitles.
Isn’t inline content to be read as a single continuous sentence, making it inappropriate for marking up subtitles (where a stronger separation between heading and subheading would be better suited)?
Depends on the heading content, the use of a character or characters is appropriate to delineate between parts of the heading. The use of CSS to modify the display value of an inline element may be used (as in the case of the example). This results in break in the content being conveyed to users (including AT users) in graphical browsers. Another option is to use the
Wow, never really knew that changing the css display property of a span would even affect AT users, that is definitely good to know.
Still feels a bit like cheating though, because a span with display:block is really just a div, so why not use a div instead (I know, the spec doesn’t allow it, but clearly that rule is a bit too strict).
I have taken your suggestion about
smallto the HTML WG list
Thanks. I am following the discussion with interest.
Noted @malarkey’s comment:
Happy to see he is marking up his headings and taglines as suggested in the HTML spec:
<h1>And All That Malarkey</h1>
<p>Since 2004, our blog’s been a favourite destination for designers and developers. Browse our <a href="http://stuffandnonsense.co.uk/blog/archives">archives</a> or read our <a href="http://stuffandnonsense.co.uk/blog/greatest-hits">greatest hits</a>.</p>
Some people in the HTML community have indicated their interest in a feature that provides a semantic indication of a subheading,
subtitle, alternative title or tagline
Here is a feature proposal to further discussion: The subline element
Oh thank heavens, something is in the works. The issue is extremely bothersome in practice. While it appears that HTML does provide plenty of element options that can be used depending on which is most appropriate, I am finding that the lack of consistency is an enormous time consumer. I can write an entire document in the time it takes me to decide which element is most appropriate for a subheading on a particular heading. Then I also have to write a rule for it in CSS when it comes out weird. That rule won’t apply to many other elements in most cases, as THIS time the structure called for an ! I’ve come to the conclusion that 75% of headings will need to have subheadings, and I may jump out the window if I have to keep stopping at every heading element to decide how I can hack a subheading into it without upsetting Mother Semantics.
I do believe there is a semantic need for a subheading element. All these b, i , strong, small, span or whatever people are using to fill in the blank aren’t encouraging human readability, accessibility or easier future maintenance. In practice, I personally am finding there is a need for a standard element, I think the proposal is exactly what we need.
I started using spans until I tested it on a screen-reader. I think I’m just going to use small. It’s as close to correct as I can get
And that’s a very good idea instead of all the span/b/strong/small combinations :)
additional thoughts on
sublineafter discussion feedback yesterday.
“subline” seems like a good idea.
Would it be possible (valid) or even meaningful to use “subline” without an actual heading before it or as a parent element? I know it’s too early too really say, but there are probably some thoughts about that already.
While I accept the argument that it was necessary to get rid of hgroup, it’s unfortunate that it’s been done without coming up with a decent replacement for some real-world cases. None of the suggested replacements really seem to do what is necessary, and nesting of whatever other elements within the h1 to force the appearance of the subtitle is at best inelegant.
For myself, I would quite like to see some analogous to the way labels are associated with fields in forms, using ‘for’.
Then, rather than using
You could use
[h1 id=”title1″]The title[/h1]
[subtitle for=”title1]The subtitle[\subtitle]
Or whatever. Basically, some way to directly associate and link the subtitle with the title without actually nesting them.
Another advantage would be that you could actually have multiple subtitles, in rare cases where they might actually be needed.
So, you could have:
[h1 id=”title1″]The title[/h1]
[subtitle id=”subtitle1″ for=”title1]The subtitle[\subtitle]
[subtitle for=”subtitle1]The sub-subtitle[\subtitle]
In fact, you probably wouldn’t need a “subtitle” element, because you could just use a “p”, which would be associated with the h1 by virtue of the “for” relationship (or whatever).
To me this seems the most flexible and easy to implement option.
I think subline could work. I particularly like the variant where subline can be used both inside or outside the h[1-6] elements.
But what about this?
<subline>The way we were</subline>
<p class="abstract">This tells the story of one small girl's climb to stardom and her subsequent fall from grace</p>
<subline id="sl1">Find about me</subline>
<h2 id="searchsection">Search the full story</h2>
<h2>The Early Years</h2>
<p>I was born in the wagon of a travelling show...
It’s a fat header for sure, but I think legitimate. Does the subline “sl2” belong to to h1 element or the h2#searchsection element? For cases like this I think it would be useful if there was a way, as a last resort, to explicitly associate the subline with its heading element. Whether that’s done as with a pointer from the subline element to the heading element like the “for” on “label” or from the heading element to the sublines like “itemref”, I don’t have a preference.
On a separate matter, I think it would be helpful if, like the h[1-6] elements, the subline had a content model of “phrasing content or the subline element” which would allow subline elements to be nested to any depth. hgroup allowed multiple levels of subheading and this would allow something equivalent.
s/phrasing content or the subline element/phrasing content plus subline elements/
I’ve just noticed the content model you had for subline. I know it’s an early draft, but “Phrasing content. Zero or more div and/or p elements.” makes no sense. Since div can contain flow content, effectively you’re allowing flow content in subline, just making authors wrap it in a div element. If that’s what you want, just make the content model of subline “flow content”. It is isn’t, you’ll need to list the exclusions explicitly.
yep, your are correct (about content model), I am in the process of updating the draft and will push major changes soonish.
FYI proposal to explicitly forbid use as subheadings
Thanks for bring that to my attention. I think it was reasonably well known that Hixie wasn’t a fan of using the small element for subheadings, but given that he would have us use “hgroup”, I don’t see that it brings us any further forward. I note that he offers no rationale for banning small other that it isn’t hgroup. Hixie is brilliant at technical matters, but there mostly aren’t any with a new element for subtitles except how to bind them to following headings. What you have there is one vote against using the small element.
I would advise against ruling in or out of any proposal at this stage unless it is technically unworkable, so I suggest that it is not helpful for the “must not” requirement for small be adopted into W3c HTML5 at this time.
What’s most useful, is a solution for subtitles that web authors can get right almost by accident. That’s what makes “subline” attractive. An inexperienced web author can see that there’s a “subline” element, guess what it’s for, use it without ever looking at a spec, and in the majority of cases it’ll be right. Given that the “small” approach seems to have gained something of a cow path, there’s some reason to favour that too. The guess-correctly requirement also encapsulates everything that was wrong with hgroup, which otherwise would have been a fine solution.
For what it is worth, I think you’ve taken on a near impossible job. Lots of people have strong and conflicting opinions, and the chances of satisfying everyone are practically nil. Consider it a success if achieve something workable and you manage to satisfy *some* people. I wish you luck.
By the way, the microdata example in the current subline proposal is invalid. The html element, since it has an itemtype attribute, needs an itemscope attribute as well.
are you a member of the html wg? if not why not/ ;-)
can I forward your comment on to the list?
No, I’m not a member. I figure I’d lose interest if I played a formal part.
Sure. Feel free to forward it to the list.
While I see the merit to the argument that there should be an element that inexperienced authors could guess the meaning of, I just can’t see that being “subline”. I can’t imagine ever guessing what “subline” was for.
@Patrick Samphire – Yes, I understand that. I’m not particularly enamoured by the name, other than it’s good enough that we can discuss it sensibly. It’s the concept and the ways in which it can be used that matters. If the right concept can be agreed upon, then no doubt a name can be chosen, but there’s no sense in expending energy debating names if the concept is flawed.
@alohci and @patrick. agree that subline is not a good name and is no more meet subhead have made other changes too :-)
I know these are details but maybe a good idea would be to add ability of using
forattribute and allow the use of
subheadoutside of the
header? Maybe a shorter name:
Any way these are just detail and IMHO the idea and proposal are great and meet all is needed :)
HTML in general lacks a good way of marking up fragment text. Maybe it’s my old high school English teachers whispering in my ear, but using a paragraph to contain text that isn’t even a single properly formed sentence seems wrong to me. If we’re just throwing any old content into a paragraph, how does it differ from a div from a semantic standpoint (other than the fact that div can contain other block elements, while paragraph cannot)?
Using lower level headlines to markup subheading content seemed like a kludge to me anyway. A proper subheading element would be a welcome addition.
The meaning of the
pelement and the term paragraph in HTML is somewhat different from what most people would consider a paragraph to be, which is where the disconnect occurs, I think. A reading of the stuff in the spec about it may be helpful.
I’ve only started to learn coding recently, and I’m amazed to see the number of Zappa fans among other coders. It reinforces my decision to keep going. But seriously, “don’tca ever wash that thing?”
As someone who converts books to HTML, it is very obvious that HTML5 fails to understand the structure of a “traditional” document. Oh, well … back to the old kludges that at least give a correct visual presentation.
I would consider aiddng new elements (particularly standalone elements) a last resort in just about any case. If an element is to be created like hgroup it makes a ton of sense for it to be one that leverages and adds value to existing elements, rather than simply standing on its own.Frances makes a great point about the semantic flaws in grouping heading elements. But I see an easier path for browser makers and designers in interpreting headings within an hgroup than the path to uniquely interpreting an entirely new standalone element.
Join the discussion.