[whatwg] Question on (new) header and hgroup
Smylers at stripey.com
Fri May 8 03:42:19 PDT 2009
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
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
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
> > * 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:
<h1>My Blog</h1> <h2>Ramblings of an internet nobody</h2>
<nav><h2>Navigation</h2> ... </nav>
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
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?
More information about the whatwg