Let <small> include subheadings?

[chaals]

Imported from bugzilla 22034

Should the small element be allowed to carry subheading info of the type hgroup was meant to allow, such as

<h2>Chapter 7 <small>The separation</small></h2>

or

<h4>The universal joint <small>assembly, transport and installation</small></h4>

This would require a relatively simple edit to the prose...

[prlbr]

I would indeed prefer to be able to use something more expressive for subheadings than <span class='…'>, which I currently do in accordance with Common idioms without dedicated elements.

Would <small> be a good choice? I’m not sure about that. I think it doesn’t match the element’s current semantics of “The small element represents side comments such as small print.” Giving <small> within <h?> different semantics would make <small> more ambiguous and complicated to interpret.

Are there better alternatives?

A new element (<hsub> or whatever) wouldn’t have the trouble associated with extending an element’s semantics. (It may have other downsides.)

---

Edit: My perception has changed, please see my comment below.

[iandevlin]

I remember this being discussed at length before, but I am not sure where so I cannot even think of where to look for the discussion to link to.
The result was "no, leave it as it is", hence the current status, but I cannot remember why.

[prlbr]

Having looked into the original bugzilla 22034 issue now (which I should have done before), I see that the suggestion is not so much about allowing <small> to mark up subheadings in addition to <small>’s current meaning, but about giving <small> a new and more abstract definition which covers both its current and further use cases, including the subheading one:

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

That’s clever and avoids the ambiguity I feared above. It would be in line with the <b> element, which increases prominence without changing importance. I think this would be useful unless there are good reasons why we definitely need a dedicated element to mark up inline side comments only, that I am not aware of.

[LJWatson]

The definition of <small> doesn't seem to preclude its use in this way, and the W3C conformance checker doesn't object to either of the test cases in the first comment.

It would be helpful to get a sense of how often developers are using a styled <span> to produce the same effect. If it's evident that this change would benefit developers/authors, it seems like a worthwhile change to me.

[kornelski]

I still prefer <hsub>.

[patrickhlauke]

An alternative pattern I often see used: <h1>Chapter 7</h1><h2>The separation</h2>

Downside here of course is that because of the limited number of native heading levels, you're "wasting" one level on this. But to me at least that feels a bit more sensible.

[iandevlin]

I don't mind allowing the use of <small> in <h1> although there do seem to be other alternatives suggested by others, another of which could be:

<header>
   <h1>Main Heading</h1>
   <small>Sub Heading</small>
</header>

which wouldn't require anything to be changed.

The only "issue" I see with the original proposal here is that the sub heading is now part of the <h1> and will be displayed as part of the title displayed on Google search results for example. But I can also see that this is the desired result, and if you don't want that, then you would mark it up some other way.

In conclusion, I see this as being useful for certain situations, so allowing it is fine in my view.

[prlbr]

Yes, there are cases where a “subheading” is actually part of the heading, e.g. in the movie title

Dr. Strangelove
or: How I Learned to Stop Worrying and Love the Bomb

(cf. movie poster) and there are cases where the “subheading” isn’t part of the heading but more like a tagline or something like that, e.g.

Pulp Fiction
a Quentin Tarantino film

(cf. movie poster).

This issue is about the former and the suggested markup would look like this:

<h1>Dr. Strangelove
<small>or: How I Learned to Stop Worrying and Love the Bomb</small></h1>

The latter would be served better with the header element like

<header role='group'>
<h1>Pulp Fiction</h1>
<p>a Quentin Tarantino film</p>
</header>

where role='group' is only necessary when the <header> element has an implied banner role that is not appropriate.

[mattur]

The h1/h2 pattern is pretty well-established (example). Perhaps a new grouping element would be useful, something like:

<headergroup>
<h1>Dr. Strangelove</h1>
<h2>or: How I Learned to Stop Worrying and Love the Bomb</h2>
</headergroup>

Or maybe something shorter.

[russmaxdesign]

@mattur I'm not sure if you are aware, but there used to be an element almost exactly as you describe in the specification. It was called the <hgroup> element. This element was dropped in 2013. See the discussion here:

http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0003.html

[stevefaulkner]

@mattur I'm not sure if you are aware

@russmaxdesign, he is well aware [snip snip - chaals]

[stevefaulkner]

@prlbr There are examples of patterns for marking up Subheadings, subtitles, alternative titles and taglines in the HTML spec. If there are additional examples you think would be helpful, please provide.

[timwright12]

I always lean on the side of standardization for things like this, especially since there seems to be a good amount of variation in real world implementations. It can bring a lot of clarity to teaching methods [for developers and machine (assistive tech - AT)] and in the end it's shown pretty well that Web Standards have benefitted the end user.

Is small the answer? I don't know. I actually liked hgroup while it was around - it solved a real problem that's now making the rounds again. I also really like the idea of using an element that's already exists (as opposed to creating a new one that will need browser support) as long as the new semantics of that element aren't so far off from the current spec that it would cause confusion or problems with AT.

On the surface, it does seem like small meets the criteria for this use case, maybe even the semantics of <i> could be tweaked. There looks to be enough validity here to investigate further, but that's just my two (ok, maybe three) cents on the matter.

[alrdytaken]

@prlbr

<h1>Dr. Strangelove
<small>or: How I Learned to Stop Worrying and Love the Bomb</small></h1>

There is an example for this in the specs using <strong> to do the same but the other way round.

<h1><strong>Flowers, Bees, and Honey</strong> and other things I don’t understand</h1>

Importance: The strong element can be used in a heading, caption, or paragraph to distinguish the part that really matters from other parts that might be more detailed, more jovial, or merely boilerplate.

[prlbr]

@alrdytaken That’s interesting, thanks. I think it’s rather convoluted. Consider this:

<h2><strong>Flowers, Bees, and Honey</strong> and other things I don’t understand</h2>
<p>…</p>
<h2>Bears, Salmon and Eggs</h2>
<p>…</p>

The code looks as if “Flowers, Bees, and Honey” is of special importance in this example and “and other things I don’t understand” and “Bears, Salmon and Eggs” are of the same kind, doesn’t it?

But that’s not what it is supposed to communicate. It’s supposed to say that “Flowers, Bees, and Honey” and “Bears, Salmon and Eggs” have the same weight in the text, being actual headings, and “and other things I don’t understand” is of lower weight – a light-hearted addition to the heading, as explained in the spec.

[prlbr]

There are examples of patterns for marking up Subheadings, subtitles, alternative titles and taglines in the HTML spec. If there are additional examples you think would be helpful, please provide.

I don’t have suggestions for additional examples at the moment, thanks @stevefaulkner. But it’s good to keep that section in mind, in case the outcome of this issue will be to change something about the <small> element which affects headings. It would be advisable to review the section about patterns for marking up subheadings etc. then.

[siusin]

Thanks all.

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.