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

[Bug 11737] Change content model of <hgroup> to single <hx> + zero or more <sh> (sub/suphead) elements

From: <bugzilla@jessica.w3.org>
Date: Mon, 14 Feb 2011 22:56:51 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Pp7Lf-0005KN-HN@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11737

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian@hixie.ch

--- Comment #1 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-02-14 22:56:50 UTC ---
> * It solves the main problem of the current content model - that some headings
> in a hgroup no longer have h1-h6 semantics (except that they do, in legacy UAs)
> - this is hard to grasp and hard to "calculate" the effects of.

I don't understand this point. Can you elaborate?


> * It is easier to style with CSS. It doesn't require the same detailed view of
> the markup structure as the current content model does.

The hgroup styling is hardly burdensome:

   hgroup > h1 { ... }
   hgroup > h2 { ... }

The proposal above doesn't really improve it, either  I don't think this is
any more intuitive:

   hgroup > h1 { ... }
   sh { ... }


> * It is semantically less confusing, as hgroup with this content model only
> contains a single hx.

I don't understand why having multiple levels of headings is semantically
confusing. It seems pretty semantically clear to me.


> * It has better semantical fallback:  Both a legacy UA and a HTML5 UA would
> create the same outline. In addition, a HTML5 user agent would EITHER see the
> whole thing as a heading (if we define it like that) OR it would see the hgroup
> as solely a container for grouping <sh> together with <hx>.

Not sure what practical effects this would have. What concrete software or
users would be affected by this "semantical fallback"?


> * It it makes the outline algorithm easier to understand and implement. At the
> same time, the current outline - as described in books and implemented here and
> there - would continue to work, except when the highest rank heading follows
> after lower rank heading(s).

The outline algorithm's complexity is not due to <hgroup>. I don't think this
proposal materially affects the complexity of the algorithm. Indeed <hgroup> is
not explicitly mentioned in the outline algorithm currently at all.


> * It seems harder to use incorrectly. The only obvious mistake that one could
> make would be to use <sh> outside a <hgroup>,  which would be relatively
> harmless (semantics of <div>).

I don't understand why that is harder than misusing <hgroup>. What failure
scenarios with <hgroup> are you expecting to commonly see?


Problems with this proposal:
* It doesn't degrade gracefully in legacy UAs.
* It doesn't pave existing cowpaths (which use <h1>/<h2>  see e.g. the HTML4
spec).
* It only supports one level of subheading.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 14 February 2011 22:56:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 February 2011 22:57:02 GMT