- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 6 Jun 2009 03:00:28 +0000 (UTC)
On Thu, 7 May 2009, Smylers wrote:
>
> * Are there significant cases where <header> needs _not_ to imply
> <hgroup>? Consider wrapping an <hgroup> inside every <header>; how
> many places has that broken the semantics? I could believe that most
> of the cases where a pager header appropriately contains multiple
> headings they are subtitles rather than subsections.
>
> Anybody who specifically needs subsections in a <header> could still
> have them by using <section> inside <header>. That wouldn't help for
> the 'Little Green Guys with Guns' example (where a section is started
> in a <header> then 'leaks out' into the following elements) -- but
> would it be unacceptable to force authors to write that with </header>
> before one of the <h2>-s?
On Thu, 7 May 2009 jgraham at opera.com wrote:
>
> The semantic that authors seem to want from an element named "header" is "All
> the top matter of my page before the main content". That could include
> headers, subheaders, navigation, asides (at least per the current definition
> of aside which I think is silly, but I digress) and almost anything else.
> Since the <header> can contain multiple distinct logical sections of the
> document, each with their own headers, it makes no sense to implicitly wrap
> its contents in <hgroup>.
I concurr with James here (it was the reason for the header->hgroup
change and the introduction of the new header).
On Thu, 7 May 2009, Smylers wrote:
>
> * Given the newness and nuance of <header> and <hgroup> and the
> distinction between them, it's likely that some authors will confuse
> them. Given that <hgroup> doesn't appear to do anything on the page
> (it's similar to invisible meta-data), it's likely that some authors
> will omit it[*1] when it's needed to convey the semantics they intend.
>
> Might actually the number of authors who mistakenly write <header>
> instead of <header><hgroup> outnumber those who need to have
> subsections in headers? That is, if <header> implied <hgroup>, might
> it fix more cases than it breaks?
On Thu, 7 May 2009 jgraham at opera.com wrote:
>
> Yes, that is possible. The thinking behind the change (or, at least, part of
> my reason for proposing it) was that it is less harmful if authors omit
> something where it would be useful than that they use it incorrectly in such a
> way that tools which follow the spec would be broken from the point of view of
> end users. In particular the old formulation of <header> would have caused the
> <h2> element to be omitted from the outline in cases like <header><h1>My
> Blog</h1><nav><h2>Navigation</h2></nav></header>, which would be confusing for
> users. On he other hand in the current formulation of the spec, the most
> likely error (omitting <hgroup>) only has the effect that that outline
> heirachy is slightly wrong, with the subheader appearing as an actual header;
> it does not lead to data loss. This seems like a much better failure mode.
I again concurr with James.
On Thu, 7 May 2009, Smylers wrote:
>
> * Are there significant cases where <hgroup> will be useful outside of
> <header>?
>
> <hgroup> exists to allow for subtitles and the like. It's fairly
> common for documents to have these -- where it's likely there's use
> for a <header> element anyway.
>
> It's much less common for a mere section of a document to warrant a
> multi-part title; is that a case which is worth solving? If it is,
> would it be problematic to force authors to use <header> there?
>
> I think that would mean that a subsection like this:
>
> <hgroup><h2>Kaboom!</h2> <h3>A Mysterious Loud Noise</h3></hgroup>
> <p>Suddenly ...
>
> Would instead have to be written as:
>
> <section>
> <header><h2>Kaboom!</h2> <h3>A Mysterious Loud Noise</h3></header>
> <p>Suddenly ...
> </section>
>
> That doesn't seem too onerous for such a niche usage.
>
> If <header> implied <hgroup> semantics (but only acted as a heading if
> there actually is an <h1> somewhere inside it) and if all current uses
> of <hgroup> could be put inside a <header> then we could avoid
> introducing the <hgroup> element.
>
> Smylers
>
> [*1] <header> is less likely to suffer from this since it's often
> replacing <div class="header"> or similar; authors want a block at that
> point in the page anyway.
On Thu, 7 May 2009 jgraham at opera.com wrote:
>
> It seems highly odd to have <header> perform a dual role where sometimes
> it means "section header" and sometimes it means "group of
> heading/subheading elements". Much more confusing than one element per
> role.
Yeah, I again agree with James. I don't really know how we'd make that
work, even, to be honest. I think we're better off keeping them separate
from each other.
On Fri, 8 May 2009, Smylers wrote:
> >
> > The semantic that authors seem to want from an element named "header"
> > is "All the top matter of my page before the main content". That could
> > include headers, subheaders, navigation, asides and almost anything
> > else.
>
> It could. But most of the above have no effect on the outline
> algorithm. In practice, how often do current <div class="header">
> sections contain headers of multiple sections, without those nested
> sections being separately wrapped in their own <div>-s (or similar,
> which could become <section> or whatever's appropriate in HTML 5)?
>
> > Since the <header> can contain multiple distinct logical sections of
> > the document, each with their own headers, it makes no sense to
> > implicitly wrap its contents in <hgroup>.
>
> You're right. What I was really thinking of is something closer to:
> inside <header> if any <hx> elements are encountered before any nested
> sectioning elements then treat all the <hx> elements as being a single
> heading.
>
> So <header> could still contain <section>-s, with their own headings.
> And a <header> with no <hx> elements wouldn't create an empty entry in
> the outline.
That would be rather weird. It would mean that this:
<header>
<h1>My World</h1>
<h2>Navigation</h2>
...
<h2>Search</h2>
...
</header>
...
<h2>My Hobbies</h2>
...would act diferently than:
<div class="header">
<h1>My World</h1>
<h2>Navigation</h2>
...
<h2>Search</h2>
...
</div>
<h2>My Hobbies</h2>
...
...which I believe would be quite confusing for people converting pages.
> Indeed. What I intended to raise for consideration (and hopefully now
> have done) is that <header> would not merge the above, because <nav>
> starts a new section inside <header>. Consider a similar example:
>
> <header>
> <h1>My Blog</h1> <h2>Ramblings of an internet nobody</h2>
> <nav><h2>Navigation</h2> ... </nav>
> </header>
>
> The spec currently has both the <h2>-s as subsections. The alternative
> I was thinking of would treat the <h1> and first <h2> as being a single
> heading (of the entire document), but keep the second <h2> (as the
> heading of the navigation).
I'm concerned that this would be too "magical" for authors to intuit
what's going on.
> My concern is that with <hgroup> being so esoteric, combined with its
> effect being largely invisible, it will hardly be used and therefore
> possibly not worth adding to HTML 5.
That's possible. We may end up removing it in the CR phase.
On Thu, 7 May 2009, Kornel Lesinski wrote:
>
> These new elements weren't clear to me initially either.
>
> Maybe instead of:
>
> <h1>HTML 5</h1>
> <h2>a new era of loveliness</h2>
>
> We should introduce <subtitle> or <tagline> elements?
>
> <h1>HTML 5</h1>
> <tagline>a new era of loveliness</tagline>
>
> or perhaps stepping a little on XHTML2's toes isn't that bad and <hgroup> can be renamed to <h>:
>
> <h>
> <h1>HTML 5</h1>
> <h2>a new era of loveliness</h2>
> </h>
I don't think <hgroup> will be used often enough to justify calling it
just <h>.
On Fri, 8 May 2009, Simon Pieters wrote:
> On Thu, 07 May 2009 17:34:21 +0200, James Graham <jgraham at opera.com> wrote:
> > Bruce Lawson wrote:
> > > <header>
> > > <h1>HTML 5</h1>
> > > <h2>a new era of loveliness</h2>
> > > <nav> ... </nav>
> > > </header>
> >
> > +--HTML 5
> > +--A new era of loveliness
> > +--Navigation
>
> Actually I believe it would be:
>
> +--HTML 5
> +--A new era of loveliness
> +--Navigation
>
> This surprised me when I used implicit sections and just wrapped <article>s
> around news items (which were <h3>s). I expected the outline to be like it was
> without the <article>:
>
> +--Site heading
> +--Page heading
> +--News item
>
> ...but instead it became (according to your and gsnedders' outliners):
>
> +--Site heading
> +--Page heading
> +--News item
>
> Maybe the spec should change here to match people's expectations better?
I think trying to fit <section> elements into the outline at the place
where the previous sibling headings would have it is far too much magic.
In general I would strongly caution against using both implied sections
and sectioning elements, but if you use both, I think it is clearer if the
sectioning elements just fall back on trivial behaviour.
(Also, trying to run the outline algorithm and work out what the depth of
the section is is not something I'd expect browser vendors to want to do
in the highly perf-sensitive selector matching code.)
On Fri, 8 May 2009, Simon Pieters wrote:
>
> <zcorpan_> hmm i wonder how <hgroup> messes up implicit sections
> <zcorpan_> maybe <hgroup> should have the same rank as its highest child h*
> element instead of always having rank 1
> <zcorpan_> so you can do
> <h1>foo</h1><h2>bar</h2><hgroup><h3>baz</h3><h4>quux</h4></hgroup>
> <zcorpan_> where baz is a subsection of bar
> <Hixie> non-issue in practice, imho, <hgroup> is almost always going to be the
> first heading
> <Hixie> and the rest of the time, people can use <section>
> <Hixie> no?
> <zcorpan_> would be nice if it worked as people expect when using implied
> sections
> <Hixie> i guess
On Thu, 7 May 2009, Tab Atkins Jr. wrote:
>
> The rank-change feels like magic and is absolutely certain to be
> overlooked in practice. What's worse, *because* this situation is rare
> in practice (I agree here with Hixie), it'll be unlikely that most
> authors even realize they're committing a mistake. When I write an <h3>
> I want it to act like an <h3>, no matter whether it's being grouped with
> an <h4> or not. If I wanted a rank-1 header, I can put an <h1> in the
> <hgroup> instead.
>
> In short, the current rank-change is likely to produce bad behavior in
> the common case (well, the common rare case, as opposed to the rare rare
> case), while inheriting rank from children produces good behavior in
> this case. Both behaviors have workarounds, but the inheriting case's
> workaround is more 'local' and obvious - you just set the rank of the
> enclosed heading to what you want; the workaround for the magic-rank-1
> case makes you to partially abandon the implicit sectioning algorithm,
> and requires an end tag far removed from the place where the trouble
> happened.
I'm not sure I really buy the argument in the last paragraph above, but
I've made this change anyway.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 5 June 2009 20:00:28 UTC