- From: Martin Janecke <w3.org@prlbr.com>
- Date: Tue, 1 Dec 2015 18:26:24 +0100
- To: public-html@w3.org
On 01.12.15 16:00, Stefan Götz wrote: > If the header of the body sectioning root is site-specific (which is > typically the case), you should use a sectioning content element for the > "page-specific" content on that page (i.e., the main content). That way, > the header applies to this section instead of the document. > > | <body> > | <header> <!-- for the site --> </header> > | <article> > | <header> <!-- for this article --> </header> > | <section> > | <header> <!-- for this section --> </header> > | </section> > | </article> > | <footer> <!-- for the site --> </footer> > | </body> Thanks, I see that this can work. I'll have to take some time to think whether that would actually be a suitable way to pursue for me, though, because not bothering an author with unnecessarily explicit markup is at the heart of the idea of light-weight markup languages. So, asking the author to mark up articles, sections etc. explicitly is not an option, and the converter would have to do that. I can let the converter do that taking things like headings as a hint. But that means programming something that user agents already do, hence mostly double work and mostly unnecessary increased complexity of the converter. As the converter does not really understand the semantics of an authors work, I'll also risk adding some semantic markup incorrectly. Is that trade-off worth it? I like that HTML now offers markup for explicit sectioning, but I think it actually makes only sense when an author of a document adds it consciously. Having the author's software add it purely automatically shifts the task of interpreting the document structure from the user agent to the author's software; it doesn't really improve anything. I wish HTML5 had introduced a less ambiguous header system with less side effects [1], e.g. something like <banner> for site specific information and <heading> for page/section specific information. Looking over to WHATWG I see that they went a different way with an additional <hgroup> element with its own inconsistencies, and we have diverging specs here. To me, it seems clear that something went rather suboptimal with how elements have been introduced for headers of different kinds. Please excuse my rambling, I can always use div, so this is not dramatic for me. Thanks Martin [1] Here's another example for side-effects: http://www.w3.org/TR/html/sections.html#the-article-element says that <article> would be technically redundant with <main>. But that does not seem to be true, because <article> is a sectioning element and <main> is not. Hence a header inside <main> (which is in turn inside <body>) is handled differently in terms of the accessibility mapping than a header inside <main> and <article>, isn't it?
Received on Tuesday, 1 December 2015 17:26:51 UTC