W3C home > Mailing lists > Public > public-html@w3.org > January 2011

Re: Why hgroup?

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 8 Jan 2011 11:51:12 +0100
To: Anne van Kesteren <annevk@opera.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>
Message-ID: <20110108115112898127.056b6333@xn--mlform-iua.no>
Anne van Kesteren, Thu, 06 Jan 2011 19:14:07 +0100:
> On Thu, 06 Jan 2011 19:04:11 +0100, Steve Faulkner 
> <faulkner.steve@gmail.com> wrote:
>> So sibling selectors are not good enough for CSS/JavaScript & shared 
>> classes for CSS ?
> They are not as good, no. People constantly complain about the way 
> <dl> works, for instance. And having <hgroup class=x> is much better 
> in my opinion than <h2 class=x>foo</h2><blah class=x>bar</blah>.

I am still analysing <hgroup>. But nevertheless, your analysis *here* 
seems wrong: <dl> is actually the HTML4 elements that resembles 
<hgroup> the most:


And, as not least you yourself have pointed out (in blogs etc): one can 
also do do

	<dt>Term 1</dt>
	<dt>Term 2</dt>

Thus, for both <hgroup> and <dl> it is the case that the second child 
is not as obvious as one is inclined to think: in <dl> it does not need 
to be a <dd> element - it could be a second <dt> element. And in 
<hgroup>, the second element  does not need to be a subtitle to the 
first child element.

So if people complain on <dl>, they might complain on <hgroup> as well, 
for quite similar reaions. However, the complaints about <dl> are 
mostly related to the bad support in use agents: DL requires user 
agents which supports the adjacent CSS selector, to be easily styled 

>> What CSS/JavaScript operations are made easier and what is the 
>> likely frequency of their use?
> Having the elements together in a single box? So they can have a 
> shared border for instance? Easily finding all <hgroup> elements in a 
> document and getting their textual contents, etc.

It does have a little bit more complicated outline semantics, though.

>> i.e. Is there a reasonable tradeoff between providing a clearer 
>> semantic and the suggested advantages of hgroup?
> The semantics are just as clear. (Personally I find container-based 
> relationships much clearer. Much more intuitive to see items are 
> related.)

The semantics, from authors' point of view, would have been much 
clearer if the element had been named just <h> instead of <hgroup>. 
Please note that in the parallel named <colgroup> elment, each <col> 
have equal weight - and corresponds to different columsn, whereas in 
<hgroup>, one of the elements is more equal than the others, and they 
all corresponds to the same "column". It really isn't clear from the 
name what a 'heading group' is - no authors has ever heard about such a 
thing. And, like Kornel L. pointed out: A h[1-6] element inside a 
<hgroup> elment is "no longer a heading — it's either a heading or a 

By changing the name to <h>, it would be much easier to see that HTML5 
*has* actually *gotten* a generic heading element, except that it 
requires a legacy h[1-6] as child element(s). This would increase its 
use. And a single <h> is much easier to style than multiple h[1-6] 
variants - as you said above.

One could also consider giving <hgroup>/<h> the same content model as 
the <menu> element: Either it is a list consisting of <h[1-6]> 
elements, or it is flow content.
leif halvard silli
Received on Saturday, 8 January 2011 10:51:48 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:29 UTC