[whatwg] Question on (new) header and hgroup

[Smylers]

jgraham at opera.com writes:

> Quoting Smylers <Smylers at stripey.com> :
>
> > James Graham writes:
> >
> > > <hgroup> affects the document structure, <header> does not.
> >
> > That explains _how_ they are different (as does the spec), but not
> > _why_ it is like that.
> >
> > More specifically:
> >
> > * 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.
>
> 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.

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

That's a good point.

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

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

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

That's true.  But if the number of failures can be minimized, it matters
less what the failure mode is.

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.

Authors don't have a good track record on accurately adding invisible
metadata.  If we can algorithmically get it right in most cases, while
leaving a way for careful authors to explicitly override it if
necessary, that may be better overall.

> > * 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?
>
> 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.

I think the two concepts are sufficiently overlapping that it isn't
really a dual role.  <header> could mean 'section (or document) header'
-- it would be used when a section's header consists of more than just a
single <hx> element.  Whether those elements are because of multi-part
titles or search boxes or whatever is a distinction that authors would
not need to think about.

Tab Atkins Jr. writes:

> Section headers with subtitles lower down in the document hierarchy
> occur with a decent frequency in my pages.  The document itself would
> have a complex <header> (possibly with an <hgroup> ), then the
> <article> would have an <hgroup> of its own.

But if the first <hgroup> were omitted and the second <hgroup> were
written as <header>, and the document conveyed exactly the same
semantics, would that actually be worse?

Smylers