This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 17787 as part of operation convergence. Originally filed: 2012-07-16 14:35:00 +0000 Original reporter: Gordon P. Hemsley <gphemsley@gmail.com> ================================================================================ #0 Gordon P. Hemsley 2012-07-16 14:35:33 +0000 -------------------------------------------------------------------------------- When an <h1> is inside an element like <section>, it is treated like a header of that section and is styled relative to the section rather than the whole page. However, if any of the other headers are used in the same way, they are only styled relative to the page. If, for example, an <h1> and <h2> are within an <hgroup> within a <section>, the <h1> will be styled relative to the section while the <h2> is styled relative to the page. This results in the <h1> actually being smaller than the <h2>, even though they are actually part of the same header and should maintain their relative size difference. A minimal testcase is included in the URL field. I have also filed a Mozilla bug on the matter: https://bugzilla.mozilla.org/show_bug.cgi?id=774098 ================================================================================ #1 Gordon P. Hemsley 2012-07-16 14:37:34 +0000 -------------------------------------------------------------------------------- Created attachment 1159 [details] Extended testcase This is a more expanded testcase that demonstrates exhaustive embedding of all <hN> sizes. ================================================================================
Not styling h2-h6 differently based on section level in general is intentional, so that you can get the same results in legacy UAs as new UAs. Hadn't considered <hgroup>, though. Not sure what to do about that case.
This is easy if we only want to support <hgroup> <h1>...</h1> <h2>...</h2> </hgroup> ...and almost as easy if we want to support further levels like that. But in CSS currently it's basically impossible if we want to support these: <hgroup> <h2>...</h2> <h1>...</h1> </hgroup> ...while still not restyling cases like this, so they work in back-compat cases: <hgroup> <h2>...</h2> <h3>...</h3> </hgroup> So should we just support the top one of these? It's better than nothing...
(In reply to comment #2) > This is easy if we only want to support > > <hgroup> > <h1>...</h1> > <h2>...</h2> > </hgroup> > > ...and almost as easy if we want to support further levels like that. I believe that's what I intended: the most basic case. > But in CSS currently it's basically impossible if we want to support these: > > <hgroup> > <h2>...</h2> > <h1>...</h1> > </hgroup> > > ...while still not restyling cases like this, so they work in back-compat > cases: > > <hgroup> > <h2>...</h2> > <h3>...</h3> > </hgroup> What are the usecases for having reverse headers in an <hgroup>? And what are the backwards-compatibility issues for a tag that was introduced with HTML5? Are there really sufficiently entrenched parsers that couldn't be updated to handle any necessary changes? > So should we just support the top one of these? It's better than nothing... The CSS I intended to be able to handle this is attached to the Mozilla bug I mentioned in bug 17787 comment 0: https://bug774098.bugzilla.mozilla.org/attachment.cgi?id=642582
The "sufficiently entrenched parsers" are those in already-shipped browsers that users aren't updating. IE6, for example. The idea is that you can use <section> and <hgroup> while using <h2>-<h6> in the old fashion, and the result is that the headings, even without CSS, render at the "right" levels in old UAs. "Reverse headers" do occur, but I'm fine with not supporting them in the default CSS. They're pretty rare. (The performance implications of the selector I used in the spec are a bit worrisome, hopefully implementors find better solutions...)
Checked in as WHATWG revision r7616. Check-in comment: Add support for automatic sizing of headings in <hgroup> if they follow <h1>. http://html5.org/tools/web-apps-tracker?from=7615&to=7616