Smylers says:

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.

Cheers

Paul d'Aoust says:

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.

Nathan says:

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:

<hgroup>
<h1]Hey I’m the Title</h1>
<h2]And I’m the Subtitle[</h2>
</hgroup>

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!

Patrick Samphire says:

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

[hgroup]
[h1]The Title[/h1]
[h2]The subtitle[/h2]
[/hgroup]

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.

Alohci says:

s/phrasing content or the subline element/phrasing content plus subline elements/

steve faulkner says:

@Alohci,

yep, your are correct (about content model), I am in the process of updating the draft and will push major changes soonish.

Alohci says:

@Steve.

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.

Alohci says:

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.

Alohci says:

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

Tom says:

@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 :)