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:

h1–h6 elements 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 header element. 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 p elements. A sample CSS styled rendering of the title and subtitles is provided below the code example.

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.

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

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]Smithstated 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:

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 span element, it kinda made a lot more sense to me than using hgroup which I remember using only once ever since I started with HTML5.

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).

But it looks like some JavaScript runs on the page stripping it out, making it look like I’m talking about an element literally called <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!

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.

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 <h2> underneath 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.

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.

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: block to 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.

<h1>
THE MOTHERS<br>
Fillmore east
</h1>

Or an author could use character such as : or - 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.

IMHO hgroup wasn’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: sh would be phrasing content element and allowed only within h1–h6 and maybe header.

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.

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 strong to 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`.

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?

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.

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.

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?

Using a p signifies it as a paragraph no? So there remains no way of marking up a subheading except styling.

What are the semantics of p? how is it conveyed to users? Or header? how is it conveyed to users?

header groups the the content and when that content is a Hx and 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.

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)

@Steve:
The Ramones would be (as you said – same semantics, different styling):
<header>
<span class="author">Ramones</span>
<h1>Hey! Ho! Let's go</h1>
</header>

But what about let’s say: W.A.S.P. – The Story of Jonathan (Prologue to the Crimson Idol).

<header>
<span class="author">W.A.S.P.</span>
<h1> The Story of Jonathan <hsub>(Prologue to the Crimson Idol).</hsub> </h1>
</header>

The <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 strong emphasis or strong importance, but I’ve always been looking at a h1-h6 as elements with strong importance – maybe it’s my bad.

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 cite, b etc., which was not so good idea IMHO.

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.

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 span and div elements, 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.

Instead of

The small element represents side comments such as small print.

make it say

The small element represents lowered prominence, but equal importance, for its contents.

It is suitable for content that is side comments such as small print, or for parts of a heading that may be omitted from an outline.

“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.

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 span and div elements, same goes for ARIA.

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 div or span might 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 small and b.

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.

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.

Hi Niels,
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 br element.

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).

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

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’.

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?
<body>
<header>
<subline>The way we were</subline>
<h1>My Life</h1>
<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>
<form><input type="search"/></form>
</header>
<main>
<h2>The Early Years</h2>
<p>I was born in the wagon of a travelling show...
</main>
</body>

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.

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.

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.

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.

@Steve
I know these are details but maybe a good idea would be to add ability of using for attribute and allow the use of subhead outside of the header? Maybe a shorter name: sh?
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 p element 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.

Using lower level headlines to markup subheading content seemed like a kludge to me anyway. A proper subheading element would be a welcome addition.

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.