Re: several messages about <section>, <p>, <hr>, and related subjects

Executive summary:

 * Many small clarifications.

 * Rewrote the outline algorithm to make Henri happy.


On Wed, 24 Aug 2005, fantasai wrote:
>
> The header and footer elements don't allow any sectioning elements, 
> which includes <blockquote>. However, headers and footers sometimes 
> include a short (but not inline) epigraph. How would you mark that up?

I've allowed <blockquote> in <header> and <footer> (though nested 
sectioning elements and headers, despite being unambiguous in the 
outlining algorithm, are still disallowed, mostly for the sake of sanity 
in writing the content model description).


On Thu, 6 Apr 2006, Michel Fortin wrote:
> Le 6 avr. 2006 � 6:44, Alexey Feldgendler a �crit :
> > 
> > This heading shouldn't be within the document's main tree of headings. 
> > It should be completely taken out, that's what "aside" means. But it 
> > can't be done in a backwards compatible way.
> 
> Hum, that's true; it seems to be a general issue with asides, not 
> limited to figures. Using aside to indicate a sidebar on a page 
> shouldn't be much of a problem because the sidebar is usually outside of 
> the main content and can have the same heading level as the main 
> content. But aside content inserted in the middle of the text is already 
> problematic from the semantic standpoint in HTML 4, and become a problem 
> to any outliner if it contains headers.
> 
> Maybe there could be a <h> element. This way you can use <h1>, <h2>, 
> etc. for the main content and <h> for any content outside the main 
> outline of the document, like asides. Its use wouldn't be mandatory, 
> just like you don't have to use the "right" heading number anymore, but 
> recommended for aside backward compatibility with outliners. It could 
> also be used in the main content for the 7th heading level and beyond.

I don't understand the problem being described here.


On Thu, 2 Nov 2006, Lachlan Hunt wrote:
> > > > http://blog.fawny.org/2006/10/28/tbl-html/
> > http://lachy.id.au/log/2006/10/fixing-html
> http://lachy.id.au/log/2006/10/fixing-html#comment-713
> 
> His comment is copied here for discussion.
> 
> > annotation: A lot of things are annotations in PDF, including comments. We
> > could use annotation for suprasegmental features like very long tooltips
> > with block-level content, whose appearance could be user-controlled (and
> > accessible by screen readers and keyboard). We could also just call blog
> > comments annotations.

Nested <article> elements cover blog comments; title="" covers short 
annotations; <aside> covers longer comments. There might be a need for 
more, but I'd like to see how the current set shakes out before adding 
more.


> > part, section and article (some in “HTML5”): A part can be a 
> > chapter (we could also just say “chapter”). Articles could be 
> > included in sections that are in turn included in parts and served as 
> > pages.

<section> should be enough for this, as far as I can tell, but if not, 
then we can add more later.


> > caption generically applicable to tables and figures: We can call it 
> > legend if you’d like.

<figure>/<legend>


> > bibliographies, tables of contents, and indices (some in “HTML5”): 
> > “For tables of contents, isn’t existing list markup good 
> > enough?” No, I’d prefer stronger associations between ToC and item 
> > than just a hyperlink. I would also like to be able to suppress 
> > display of ToC in some presentations. Of course I can do that with 
> > divs.

I'm not sure what to do here. We have the semantics in there already -- 
ToC using headers/sections, indexes using <dfn>/<i>/<b>, bibliographies 
using <dl>/<dt>/<dd>/<cite> -- but I would say that doing anything more 
with them probably requires scripting or user agent support. I'm not sure 
what else to do.


> > nonstruct for generic groupings: We can use it to group noncontiguous
> > elements, useful in e.g. error reports on submitted forms or Ajax
> > applications. E.g., nonstruct group=”X”.

<div>, aria.


> > formula: “But doesn’t that fit into the category of science and 
> > mathematics that you had issues with earlier?” Yes, but this one we 
> > *need*.

Math markup is currently an outstanding issue. I've no idea what to do 
with it though.


On Tue, 14 Nov 2006, Simon Pieters wrote:
> 
> I'm a little confused about the headings and sections in HTML5, in 
> particular creating an outline. [1]
> 
> What's the outline of <body><h1>foo</h1><h1>bar</h1></body>?
> 
> I read it like it will be:
> 
>   root
>    - <body>: "foo"
>    - new sectioning element: "bar"
> 
> Is that correct?

Yes.


> If it is, shouldn't such documents be non-conforming or at least such 
> usage be considered discouraged?

Why?


On Thu, 4 Jan 2007, Ron van den Boogaard wrote:
> On 4-jan-2007, at 9:05, Henri Sivonen wrote:
> > On Jan 4, 2007, at 02:58, Ian Hickson wrote:
> > > 
> > > What's the use case for <div> elements containing inlines?
> > 
> > It seems to me that the usual use case is avoiding <p>, because the 
> > author is too shy to claim that the particular piece of inline content 
> > constitutes a paragraph or the author doesn't want to undo the default 
> > style for <p>.
> 
> Which seems to make a good case to introduce a mechanism that indicates 
> a degree of importance to the <p> tag. E.g. <p1>, <p2>, <p3>, etcetra. 
> Analogical to the <h1>, etc. tags.
>
> Having multiple <p> tags would allow for different paragraph uses with 
> different semantic importance and different presentation. Thereby 
> lessining the need for a lot of <div>'s.

That doesn't seem much of an improvement...


On Thu, 4 Jan 2007, Michel Fortin wrote:
> Le 2007-01-03 � 20:26, Ian Hickson a �crit :
> >
> > Hmm. I guess we could say it is 
> > block-or-structured-inline-but-not-both, like most of the other 
> > elements.

This is moot now that phrasing is just a subset of prose.


> This would make things easier with the Atom spec which says this about 
> HTML content:
> 
>    Example atom:title with HTML content:
> 
>    ...
>    <title type="html">
>      Less: &lt;em> &amp;lt; &lt;/em>
>    </title>
>    ...
> 
>    If the value of "type" is "html", the content of the Text construct
>    MUST NOT contain child elements and SHOULD be suitable for handling
>    as HTML [HTML]. HTML markup within SHOULD be such that it could
>    validly appear directly within an HTML <DIV> element, after
>    unescaping.

At this point that's the same as is allowed in <body>.


On Sun, 11 Feb 2007, Benjamin Hawkes-Lewis wrote:
>
> Some web documents are standalone, but many if not most belong to a 
> hierarchy of documents.
> 
> There has long been confusion about the correct way to indicate the 
> document hierarchy from within a given document. How should <title> 
> elements be written? How should site logos be marked up? Should <hX> 
> elements be used to indicate the structure of an individual page, or 
> also include titles from further up in the document hierarchy? Is such 
> markup superfluous to typed <link>s?
> 
> After text fallbacks, heading elements are arguably the single most 
> important accessibility feature HTML offers. They allow assistive 
> technology users to jump between sections of a document, rather than 
> being forced to listen to or read the entire stream.
> 
> WHATWG's specifications should establish clear guidelines about how 
> document hierarchy can be indicated. The web is a big place; its users 
> deserve consistent and efficient answers to the fundamental question of: 
> "Where am I?"

Does this help?:

http://www.whatwg.org/specs/web-apps/current-work/#distinguishing

I'm not sure if we really want that, though.


> Some suggestions for further discussion follow.
> 
> <title>
> =======
> 
> WHATWG should give two pieces of guidance for when a <title> is used to
> indicate a document's place within a hierarchy of documents:
> 
> 1) Unit titles should be listed from least to greatest (e.g. "Chapter 15 
> — Charles Dickens, Great Expectations — The Virtual Library" not 
> "The Virtual Library — Charles Dickens, Great Expectations — Chapter 
> 15"). This seems to be the most convenient form when interacting with 
> web content as a stream, since it puts the information that changes most 
> frequently at the beginning. Compare how the titles of windows are 
> arranged in desktop environments.

I don't know if we really need to go to this level of detail.


> 2) Unit titles should be separated by sane punctuation that does not 
> impair aural or tactile accessibility, e.g. in English an em dash not 
> guillemots. Ideally, WHATWG could suggest punctuation for different 
> languages.

I really don't think we should go to this level of detail.


> <link>
> ======
> 
> "Interactive user agents should provide users with a means to follow the 
> hyperlinks created using the link element, somewhere within their user 
> interface."
> 
> Since "Where am I?" is a fundamental question, and since this has 
> already been implemented in many user agents, this should be a MUST not 
> a SHOULD.

So if a Web browser is used to display a banner on Times Square, it must 
provide a button somewhere on times square to navigate through the links?

No, we can't require that in all cases. There are some UAs where it simply 
would make no sense.


> <h1> - <h6> and <header>
> ========================
> 
> I think the current draft is much less clear here. <h1> to <h6> are said 
> to "define headers for their sections". Should this, or should it not, 
> include headers for larger document units that the document happens to 
> be part of?
>
> If it should, how can document mappers, especially those used by 
> assistive technology, distinguish the important local headers from more 
> general headers (such as site logos). And if there is a way for them to 
> distinguish such headers, how should they treat legacy content?
>
> If it should not, the specification needs to state this, given the past 
> history of people sometimes (counter-productively IMHO) using <h1> for 
> the site header on sub-pages.

Does the section cited above answer this?



On Mon, 2 Apr 2007, Henri Sivonen wrote:
>
> The spec should probably mention that the name <footer> doesn't imply 
> being placed at the end.
> 
> For example, if at http://www.helsinki.fi/~rkosken/kirjallisuus/hc.html 
> the text at bottom right qualified as a footer, surely the text at top 
> right would qualify as well.

Added an example.



On Fri, 25 May 2007, Mihai Sucan wrote:
> > 
> > I don't think a document outline DOM API is something that has a great 
> > deal of demand. It's also something that could be implemented in a 
> > JavaScript library or on the serverside. Generally speaking we want to 
> > keep the APIs in the spec to a minimum, limiting them to primitives 
> > that are useful for a broad range of purposes, rather than having many 
> > special-purpose APIs. So I haven't added the outline DOM idea to the 
> > spec.
> > 
> > The main reason for having this section is to enable scripts and user 
> > agents to create outlines in user interfaces without ambiguity about 
> > what is a section. This is an area that has historically been very 
> > much underdefined. We shall have to see, with implementation 
> > experience, whether this is useful or not, and what UA implementors 
> > will do with it.
> 
> I'm skeptical about UAs implementing the outline algorithm.

It's unlikely to happen soon, but it's more likely if we have it defined.


> If there would have been a very high demand for UAs to implement some 
> kind of document outlining algorithms, that would have happend already, 
> with or without any standard algorithm.

Possible.


> However, we have seen sites which create their own document outlines. 
> Why? Because the demand was even higher. I've created my own document 
> outlines, specific to my documents (either manually, or scripted).
> 
> Also, let's look at UserJS, Widgets and even UserCSS. I've seen UserJS 
> scripts which generate document outlines, same goes for CSS. Of course, 
> CSS is very limited compared to JS - but yes, I've seen such user 
> styles. Given Widgets are small web application packages 
> (HTML+CSS+JS+etc), it is conceivable some of them will also need 
> document outlining.
> 
> I agree there's a demand for document outlining within an UA, but that's 
> all theoretical, in ones imagination. I did think long time ago, and I 
> still do, about how good would be to have UAs which implement document 
> outlining and several other features which would really make *semantics* 
> more obvious for the average Jane/Joe user. Yet, *today* the "need" is 
> on the web.

I don't disagree. Like I said, I expect scripts to use the algorithm too.


On Tue, 29 May 2007, Leif Halvard Silli wrote:
>
> The subsection 8.1.2.5. �Restrictions on content models� puts 
> restricions �for historical reasons� on the content model of amongst 
> others, the P element (my understanding is that the restrictions are 
> only valid for the HTML5, but not for XHTML5 - please, correct me if I 
> am wrong):
> 
>  A p element must not contain blockquote, dl, menu, ol, pre,
>  table, or ul elements, even though these elements are technically
>  allowed inside p elements according to the content models described
>  in this specification. (In fact, if one of those elements is put
>  inside a p element in the markup, it will instead imply a p element 
>  end tag before it.)  

Oops, this one is no longer relevant, since XHTML5 no longer allows <p> to 
contain those either.


> I'd like to question these restricions. I think that at the very least, 
> TABLE should be allowed inside the P element. The reason is that MSIE (I 
> tested version 6 and 7) accept TABLE in P, regardless of whether it is 
> in Quirks-Mode or in Standards-Mode. Even Firefox-Opera-Safari (FirOpSa) 
> allow TABLE inside P - allthough they only do so when in Quirks-Mode. 
> When in standards mode, FirOpSa behave according to the HTML5 
> restriction quoted above.  I have a test page here, where the DOCTYPE 
> get MSIE into standards mode, and FirOpSa into Quirks-Mode, and with two 
> TABLE elements in the second P-element of that page: 
> <http://www.malform.no/prov/content-model/index.html>.

I think with Acid2 testing this it would be a bad idea to change this at 
this point.


> As the test page also shows, it would not be _that_ simple to allow 
> BLOCKQUOTE, DL, MENU, PRE or UL in today's browsers. However, if you 
> stuff any of those elements in a SPAN element, then they become more 
> digestible - for Firefox and Safari and little brother iCab (but not for 
> Opera or MSIE). (And when reading section 3.12.18. �The span element�, 
> SPAN is said to be allowed to contain �Otherwise: any inline-level 
> content�, i.e. structured inline-level content as well � thus stuffing 
> e.g. UL in SPAN seems to be in line with the content-model. It is 
> unclear to me whether the restrictions in 8.1.2.5 is meant to also count 
> for SPAN inside a P - but I assume they are.)

The spec has changed a lot since that comment, but see the XXXSPAN bits in 
the spec markup for hints that we've considered this. Sadly I couldn't get 
it to work well in enough browsers under enough conditions to make it 
worth it. It's also very ugly.


> I'd also like to mention that both Firefox, Opera and Safari allow the 
> restricted elements, as well as P itself, to become nested inside a P 
> provided you stuff them inside a OBJECT. (See the mentioned test page). 
> Whether this is allowed according to HTML401, is unclear to me. But 
> HTML401 gives many code examples, using P without closing tag (thus 
> sometimes open for interpretatations) where P inside OBJECT inside P is 
> used. And it is at least not forbidden. And the HTML validator accepts 
> it. Note that FirOpSa _nest_ P inside P this way: You will see a P with 
> margin, padding and border inside its �parent P�. MSIE does not allow P 
> inside OBJECT though.
> 
> The MAP element is also worth mentioning in this context. It may appear 
> inside P. And it may also contain block level elements. Thus via MAP a 
> P-element may contain another P-element. It is my experience that those 
> browsers that nest P inside P via the OBJECT (I am thinking about when 
> the embedded content of OBJECT is unavailable), does not handle P inside 
> MAP inside P. (To see if User Agents does not handle P inside MAP inside 
> P or P inside OBJECT inside P, one must apply BORDER, MARGING and or 
> PADDING, and perhaps background color - then you will see how it falls 
> apart. Opera, for instance, does not handle P inside MAP inside P.)
> 
> Anyway, the whole thing about what P may or may not contain in HTML, is 
> much more blurred than a fast reference to �historical reasons� can 
> tell. Hence it would be better to try to un-restrict the content-model 
> of P as much as possible. Because if HTML5 will continue to apply these 
> restricitons on P, then authors must continue to work with paragraphs in 
> HTML in quite unintuitive ways.

I've also had a lot of feedback saying that allowing lists inside 
paragraphs, and similar constructs, is confusing to authors. So I don't 
really know what to do here.

For example:

On Tue, 29 May 2007, Martin Payne wrote:
> 
> When would it ever make sense to do this though? Surely you would never 
> want to put a table inside a paragraph, because tables and paragraphs 
> are two totally different things. I also can’t see why you would put a 
> paragraph inside a paragraph—surely it should either just be one 
> paragraph, or be two completely separate paragraphs.


On Tue, 29 May 2007, Benjamin Hawkes-Lewis wrote:
> 
> What does this mean? IMHO the criterion needs to be: do printed works 
> ever place tables inside paragraphs? I don't know the case for tables; 
> but I know paragraphs regularly include block quotations.

This has been debated before. Personally I agree with you, but it seems 
that this is not as clear cut as we would like to believe.


On Tue, 29 May 2007, Leif Halvard Silli wrote:
> 
> [...]
> 
> The fact that the above is possible in XHTML5, but not in HTML5 gives 
> XHTML5 an advantage. But it was my impression that the WHATwg wants to 
> �lift� the status of HTML to a higher level - if I may put it that way.

I personally don't really care either way, and would be happy for XHTML 
and HTML to each have their own unique strengths and weaknesses. However, 
there are certainly those who believe that they should have equivalent 
abilities so as to make migration across them trivial.


Regarding <p><table>, I don't really see that much value in reverting what 
HTML4 required, especially given that it doesn't give us anything more 
than <p><table>, and allows for <p><table><tr><td><p>. So I haven't 
changed anything.


On Sun, 5 Aug 2007, Ben Boyle wrote:
> 
> http://dev.w3.org/html5/spec/Overview.html#the-header
> 
> Clearly written. I have some comments on the content model.
> 
> First a minor suggestion around cross-referencing: "any sectioning 
> elements (such as section)" - I suggest we link "sectioning elements" to 
> http://dev.w3.org/html5/spec/Overview.html#sections, rather than linking 
> to only the section element.

Fixed all the references to sectioning content.


> Content model: 2 considerations.
> 
> 1. should <header> (and footer) allow <nav>?

No, because that would seriously screw up the outlining algorithm. That 
is, it's fine for them to contain links, but they can't contain sections 
(which is what <nav> is), since they are giving the headers for a section.


> 2. should <header> not require h1-6?

The whole point of the element is to group <h1>-<h6> elements. :-)


> Here's an example: http://www.alistapart.com/d/slashdot/indexwithoutmarkup.html
> (and the article that goes with it: article:
> http://www.alistapart.com/articles/slashdot/)
> Look for <div class="header"> in the source.
>
> Cowpaths this demonstrates:
> 1. nav is often included in "header" sections
> 2. "header" sections sometimes don't contain a h1-6 element (why?
> because a header is often a header for an entire website, not the
> individual documents).

I think this case should have been marked up as follows:

   <h1><img src="images/title.gif"
            alt="Slashdot. News for Nerds. Stuff that matters."></h1>
   <nav>
    <ul>
     ...

...and they shouldn't have been in the same element at all. Indeed I don't 
see the need for a <header> here at all.


> I actually agree with the content model for <header> but want to raise 
> this concepts as I think they are quite likely to occur and we should 
> think about what we want to do about it. I think the choice of the term 
> "header" is perhaps at fault here. If it were "heading" it would more 
> closely match the intent (to my mind, at least).

I think the intent is <header>, and that the mistake is treating it as if 
it was <heading>. :-)


On Tue, 18 Sep 2007, Lachlan Hunt wrote:
>
> As discussed in IRC today, the spec should include an example of marking 
> up pullquotes using aside and blockquote.
> 
> <article>
>   <p>blah blah blah...
> 
>   <aside>
>     <blockquote>
>       pullquote...
>     </blockquote>
>   </aside>
> 
>   <p>blah blah blah...
> </article>

Added.


On Thu, 1 Nov 2007, Keryx Web wrote:
>
> Ian Hickson is reading his mail so fast this almost feels like IM ;-)

Not quite, it seems. :-)


> > Why is <p> inappropriate? According to HTML5, it's exactly the element 
> > you want, in fact.
> 
> a) To my linguistic senses that's not a paragraph

Why not?


> b) I've seen several people use the div-element (like it or not). Should 
> all their work suddenly be called non-conformant?

The spec now allows <div> in these cases, but I still think it's wrong.


On Fri, 2 Nov 2007, Philip Taylor wrote:
> 
> I would like to use the new sectioning elements (<section>, <article>, 
> <header>, etc) so that HTML5 UAs can process my documents in new 
> improved ways, while still degrading gracefully in current UAs (i.e. 
> acting as similarly as possible to the HTML5 behaviour, preferably 
> without requiring me to use complex styling or scripting).
> 
> A simple ungracefully-degrading example would be:
> 
>   <style>header { padding-left: 2em; background: #ffa; }</style>
>   <header>
>     <h1>BGP Wedgies</h1>
>     <p>Copyright 2005</p>
>   </header>
> 
> Pre-HTML5 UAs will not have the correct default presentation, so it can be
> improved to:
> 
>   <style>header { padding-left: 2em; background: #ffa; display: block;
> }</style>
>   <header>
>     <h1>BGP Wedgies</h1>
>     <p>Copyright 2005</p>
>   </header>
> 
> The HTML Design Principles document (r1.18) gives almost exactly this example,
> under "Degrade Gracefully".
> 
> That appears to work fine in (at least) Opera 9.2 and Safari 3. But it 
> doesn't work in Firefox 2 (or trunk) - the parser closes the unknown 
> element before the first block child (in this case, <h1>). It also 
> doesn't work in IE7 - the parser treats unknown tags as empty elements. 
> In both cases, it is either difficult or impossible to write a script 
> that identifies the intended child elements and reconstructs the DOM.

Firefox 3 is hopefully going to support these new elements. IE can be 
faked out using createElement().


> Possible solutions:
> 
> * Use <div class="header">...</div> instead of <header>...</header>, and
> change the CSS to use '.header' instead of 'header'.
> 
> That prevents HTML5 UAs from detecting the element's semantics and 
> applying the new header-specific processing that justifies the existence 
> of <header> in the first place. It also fails to provide any direct 
> encouragement to UAs to start supporting <header>.
> 
> * Use <header><div class="header">...</div></header>, and change the CSS to
> use '.header' instead of 'header'.
> 
> HTML5 UAs will parse that correctly and see it's a header. Firefox/IE 
> will parse it incorrectly, but still apply the stylesheets. Scripts that 
> try to process HTML5 sectioning elements (e.g. to generate a table of 
> contents) will not work in Firefox/IE without being specifically written 
> to detect this non-standard way of marking up sections.

Indeed, this is what I would encourage in the meantime.


> A relatively simple script can largely fix the DOM in FF/IE, e.g.:
> 
>   var hs = document.getElementsByTagName('header');
>   for (var i = 0; i < hs.length; ++i) {
>     if (hs[i].childNodes.length) continue;
>     var h = document.createElement('header');
>     h.appendChild(hs[i].nextSibling);
>     hs[i].parentNode.replaceChild(h, hs[i]);
>   }
> 
> * Use <header><span class="header">...</span></header>, and change the CSS to
> use '.header' instead of 'header'.
> 
> This works roughly like the previous solution, but (so far as I can 
> tell) Firefox parses it correctly and does not need any script to fix 
> the DOM afterwards.
>
> * Use <header><span>...</span></header>, and don't change the CSS.
> 
> This works roughly like the previous solution, but it is more concise, 
> and the standard CSS element selectors and any scripts expecting an 
> HTML5-like DOM will work without scripting in all current significant 
> desktop browsers except IE, and will work in IE with the above script.

I wouldn't encourage these as much.


> * (Are there better alternatives that I've missed?)

Wait a few years? :-)


> Problem: <header><span>...block-level elements...</span></header> is the 
> simplest solution to many of the degradation concerns, but is currently 
> non-conforming in HTML5.
> 
> Principle: "Degrade Gracefully" says "HTML 5 document conformance 
> requirements should be designed so that Web content can degrade 
> gracefully in older or less capable user agents, even when making use of 
> new elements, attributes, APIs and content models."
> 
> Proposal: Make <header><span>...block-level elements...</span></header> 
> conforming.

It's ugly as hell and doesn't work everywhere, as I understand it. I 
considered adding this at one point (it's still in the spec, but commented 
out), but decided against it for reasons I now forget.


On Mon, 12 Nov 2007, Daniel Glazman wrote:
> 
> With my Nvu hat on, the section element is a problem to me. It does not 
> give me enough power or flexibility and requires exactly the same amount 
> of JS code ol-plain-flat-html code required in the past. Let me give you 
> a concrete example seen a zillion times on the web :
> 
>    <section>
>      <h4><img src="l.gif" alt="T">he raise of a new standard</h4>
>      <p>bla bla bla</p>
>    </section>
> 
> First I would like the DOM interface for section to retrieve for me the 
> title of the section if any. When I say the title, I am not saying that 
> the result here should be
> 
>    he raise of a new standard
> 
> I need and want
> 
>    The raise of a new standard
> 
> See what I mean ?

Yeah -- there's a comment in the spec somewhere asking if we want an 
attribute that is like textContent/innerText, but which handles <img alt> 
and <bdo> with some sanity. I take it you are voting in favour of this. :-)


> Furthermore, I think the model for section is not enough. It clearly 
> assumes the title of a section is always IN the section itself. This is 
> clearly not the case when your document outline lies outline of the main 
> flow. I recommend changing as follows :
> 
>   if a section element has an attribute 'headerref' then this attribute
>   contains the URL of an element being the header of the section ;
>   otherwise the header is as originally proposed the first heading
>   element inside the section. For example :
> 
>   <nav>
>     <a href="section1.html" id="TheRaiseOfANewStandard">The raise
>        of a new standard</a>
>   </nav>
>   ...
>   <section headerref="#TheRaiseOfANewStandard">
>     <h6>this is **not** the section's header</h6>
>     <p>bla bla bla bla</p>
>   </section>
> 
> That way, it's still possible to retrieve the outline of the document 
> from the sections w/o looking at the navigation boxes.
> 
> (please, no religious comment about the name 'headerref', I just DO NOT 
> care about the name, I want the feature)

I don't understand the proposal here. What's the use case? Why not just 
duplicate the text?


On Wed, 5 Dec 2007, Lachlan Hunt wrote:
>
>   The spec should probably require heading levels to be used in the 
> correct order, so that a lower level heading must be preceded by a 
> higher level heading.
> 
> e.g. This should be non-conforming.
> 
> <body> <h6>heading</h6> <h1>heading</h1> </body>
> 
> See also. http://www.alistapart.com/comments/previewofhtml5?page=3#23

We could require headers' rank to match the level they're at, but that 
rather defeats the entire point of having magically-ranked headers. I'm 
not sure how else to do this... we want to allow arbitrary copy/paste, 
that's rather the whole point. How would you phrase the requirement?


On Wed, 5 Dec 2007, Karl Dubost wrote:
> 
> Use case 1
> 
> 1. Reading a blog post, interesting excerpt
> 2. Cut and paste in a blockquote
>    http://www.w3.org/html/wg/html5/#headings0
>    Which is difficult to handle in terms of CSS.

I can't tell if you are arguing this use case is in favour of what Lachlan 
suggested, or against it. It seems like an argument against, though, so 
I'll assume that's what you meant.


> Use case 2
> 
> I'm writing a long document, article. I'm not sure yet about the sections and
> the level of headings.
> What the authoring tool should do?
> Create empty headings?

Why is there a problem? You can move the sections and headings around as 
you edit the document.


On Wed, 5 Dec 2007, James Graham wrote:
> 
> As a general rule, I would say that a document should be conforming any 
> time that it is published to the web for general consumption. For a wiki 
> like wikipedia that means that each time you click "save" you should 
> have a conforming document, but each micro change you need to get 
> between the document you start with and the one you end with need not 
> leave you with a conforming document.

Indeed.


On Wed, 5 Dec 2007, Daniel Glazman wrote:
> >
> >   The spec should probably require heading levels to be used in the 
> > correct order, so that a lower level heading must be preceded by a 
> > higher level heading.
> > 
> > e.g. This should be non-conforming.
> > 
> > <body> <h6>heading</h6> <h1>heading</h1> </body>
> 
> COUGH COUGH COUGH.
> 
> And suddenly zillions of web sites can't automatically convert from 
> html4 to html5.

Actually, such conversion would be readily possible using an automated 
tool. It wouldn't make it possible to just copy content over, though, 
certainly -- and that's why this isn't currently required.


On Wed, 5 Dec 2007, James Graham wrote:
> 
> Therefore, from the point of view of a requirement to have headings in 
> order, it makes sense to regard <header>s as representing a single 
> heading element equal to the highest rank child; i.e.

...actually <header> always has rank 1.


On Wed, 5 Dec 2007, Doug Jones wrote:
> 
> I guess I don't get it, that is <header> and <hx> within <header>.
> 
> You have <header><h3>...</h3></header> constructs. Shouldn't the h3 be 
> h1? -the first level in the header (and the section).

It doesn't matter, according to HTML5 as defined today.


> It is my interpretation that hx levels are independent within each 
> header. So all the following h1 elements have the same heading level. Or 
> is the Sub-title in the second example a heading level below the Title 
> in structure?
> 
> <section>
>   <header>
>     <h1>Section Title</h1>
>   </header>
> </section>
> <section>
>   <header>
>     <h1>Another Section Title</h1>
>   </header>
> </section>

The above is two sibling sections.


> <section>
>   <header>
>     <h1>Section Title</h1>
>   </header>
>   <section>
>     <header>
>       <h1>Section Sub -title</h1>
>     </header>
>   </section>
> </section>

The above is a section and its subsection.


On Thu, 6 Dec 2007, Ian Hickson wrote:
> 
> If you are asking why the spec doesn't allow elements to have a mix of 
> inline-level and block-level child elements, the reasons the spec 
> doesn't allow it include (off the top of my head):
> 
>  * Mixing inline and block content makes it hard for non-visual UAs to 
>    determine where to pause (the "paragraph breaks" for lack of a better 
>    term)

Fixed by defining paragraphs even in the face of weird mixed markup.


>  * Mixing inline and block content makes it very hard for editors to
>    properly allow editing of content.

Not fixed, but this was a problem in HTML4 with <div> and with CSS anyway, 
so, well, tough.


>  * Mixing inline and block is semantically ambiguous (in the same way 
>    that having a <p> element directly inside an <ol> is ambiguous), which  
>    makes it hard to analyse, e.g. with scripts.

Again, tough.


>  * The use cases for mixing inlines and blocks aren't very clear, and can 
>    always, to my knowledge, be better addressed without mixing inlines and 
>    blocks (e.g. by using explicit <p>s).

I still think this is true, but oh well.

"Inlines" and "blocks", as they used to be known, can now be mixed, and 
are all considered "prose content".


> BTW, in recognition that these restrictions would otherwise prevent 
> practices that are quite reasonable, the HTML5 spec relaxes the 
> requirement as follows:
> 
>  * A number of elements are considered inline-level where possible (e.g. 
>    <ol>, <ul>) -- though note that this is controversial, since it (a) 
>    can't be used in text/html much and (b) seems to be difficult for 
>    editors, defeating part of the point of the restriction (though it's 
>    not as difficult as arbitrary mixed inlines and blocks).

This is no longer the case.


>  * <input type=hidden> is allowed even when other types wouldn't be -- 
>    this is probably going to be extended to cover tables too, at some 
>    point.

Unchanged as yet.


>  * <div> allows inline content (though not mixed content) to allow people 
>    to make custom widgets and work around ommissions in the language
>    (though I'd like to tighten this up so it's harder to abuse).

I'd still like to tighten this up, but might not.


On Thu, 6 Dec 2007, Sam Ruby wrote:
> 
> Ian's point about wanting to continue to flag a <p> element as an 
> immediate child of <ol> is a good one; the issue here is that the 
> current restrictions disallow things that cause no ambiguity or interop 
> issues.  An example of this would be the notion of a "strictly inline 
> element", like an <a>, which excludes the possibility of it being the 
> only element in a <footer> like I have done, merely because a <footer> 
> deigns to allow block level elements as an alternative.

This is now allowed.


On Thu, 6 Dec 2007, Jirka Kosek wrote:
> 
> On a more serious line -- why to bother with implicit paragraph when it 
> doesn't alter DOM and CSS rendering? If the only reason is validation 
> then schema (yes, markup language should have schema IMHO) should be 
> relaxed.

Well, we have to define what things mean, even if they don't affect the 
DOM or scripts or CSS. Otherwise, what's the point. :-)


On Wed, 9 Jan 2008, Simon Pieters wrote:
>
> See: http://forums.whatwg.org/viewtopic.php?t=42#537
> 
> Apparently WebbIE prepends "Page Headline:" to all <h1>s, so only using 
> <h1>s like HTML5 currently recommends results in usability problems for 
> users with WebbIE.

I respectively suggests that's a bug in WebbIE.


On Sat, 19 Jan 2008, Ben Boyle wrote:
> 
> http://dev.w3.org/html5/spec/Overview.html#the-nav
> 
> I like this concept, I can see it as very useful to mark sections of the 
> page as being "mostly navigation" (i.e. not content). I say "mostly" as 
> I imagine these sections could include a bit of prose in the mix... if 
> it were going to be restricted to links only then the XHTML2 nl 
> (navigation list) element would have been more appropriate. While not as 
> explicit as nl, I think I will find nav more useful when authoring. 
> Flexibility is good.
> 
> Except, I can see the content model skewing the situation. I may be 
> reading the spec wrong, but it says nav belongs to the category of 
> "sectioning content". Doesn't this mean that using <nav> ... </nav> 
> implies a new subsection, with it's own potential header, footer and 
> address components? I think nav would be more appropriate as a component 
> of a section (the same as header, footer and address, which are not in 
> the "sectioning content" category). Furthermore, I think some nav 
> belongs within the header/footer context, and this is explicitly 
> disallowed in the current spec (those elements may not contain 
> "sectioning content").
> 
> Some examples supporting this perhaps?
> 
> 1. www.apple.com
> Look at div#homefooter. I will make the leap this could be <footer> in
> HTML5. Now look at its contents ... wouldn't <nav> be appropriate for
> p.links.right? (Possibly for p.links.left, but maybe address would be
> good there too).
>
> 2. http://www.microsoft.com/windows/products/winfamily/ie/default.mspx
> Consider table#msviFooter ... wouldn't a footer > nav context make sense again?

No, <nav> is for user-primary navigation sections, like the left-hand 
column on Slashdot (if you're logged out, anyway). Footers might contain 
navigation, but those aren't navigation sections. We're not trying to 
obsessively mark up all groups of links as navigation, we're trying to 
mark up the primary navigation blocks.

I've added an example showing this.


> 3. http://www.opera.com/
>
> Let's mix it up a bit ... div#top and div#menu are a good example of a 
> header with a sibling (not nested) nav element. This would be ok in 
> HTML5 (except that it is implied in the spec that the nav would be its 
> own section rather than a component of the first ancestor sectioning 
> content: the body element in this example). Still, there second p within 
> div#footer again looks like nav nested inside footer (in HTML5 parlance) 
> to me.

I assume the page has changed since you wrote the e-mail.


> 4. http://www.mozilla.org/
> Whoah, wait up a minute. div#header contains a ul with navigation...
> that would be header with a nested nav, right?

Most of that page might arguably be in <nav>s, but I wouldn't put the 
navigation links in the <header>. I would say the search form and the 
links at the top should be in a separate section than the header.


> 5. http://www.w3.org/
> W3C have no wrappers for their "header", just h1-2 tags. Fine in all
> HTML languages afaik. There's a div.banner that could be nav. Whether
> or not there should be a "footer section" (or it could be implied by
> the content) will be a question that plagues many authors I am sure
> ... and whether or not legal links are "nav sections" ...

There's a number of places there that could be considered <nav>s (some 
with headers, some without), but none of them are themselves inside 
<header>s, IMHO.


On Sat, 19 Jan 2008, Simon Pieters wrote:
> 
> I can see the value in having <nav> be a sectioning element with its own 
> subsections. e.g. on w3.org home page I would say that the whole left 
> sidebar is a <nav>. OTOH I have also seen pages that use navigation in 
> headers and footers, so I would expect authors to be surprised when 
> their <header><nav> or <footer><nav> markup doesn't validate when they 
> make an effort to convert their <div> soup to HTML5. Hence, I agree that 
> <nav> should be allowed to be nested in <header> and <footer> (but then 
> have transparent content model).

The primary use case for <nav> is allowing people to skip over them to go 
to the main content, and then to focus onto the main navigation section 
when they want to go elsewhere. I don't see value in mixing this and the 
concept of headers.


On Fri, 22 Feb 2008, Leons Petrazickis wrote:
> 
> Has pagination been addressed? Would the suggested way to mark up this:
> 
> [ 1 ] [ 2 ] [ 3 ] [ 4 ] ...
> 
> or this:
> 
> <<First <Prev 1 2 ... 30 31 Next> Last>>
> 
> be a <ul> in a <nav> element?

I'd just use a <p> element with a bunch of <a> elements (with rel= 
attributes, but that's by the by).


> Also, I am not sure what the overall page markup would be. <article> 
> requires a stand-alone document, while <section> is more generic but 
> gives "chapters" as an example usage.
> 
> Option 1:
> 
> <article id="page2">
> Lorem ipsum.
> 
> <nav><ul id="pagination">...</ul></nav>
> </article>
> 
> Option 2:
> 
> <section id="page2">
> Lorem ipsum.
> 
> <nav><ul id="pagination">...</ul></nav>
> </section>
> 
> Option 3:
> 
> <article>
> <section id="page2">
> Lorem ipsum.
> 
> <nav><ul id="pagination">...</ul></nav>
> </section>
> </article>
> 
> Is any of these options the recommended one?

All seem ok to me. I guess using <section> might be best.


On Fri, 22 Feb 2008, Christoph P�per wrote:
> 
> For a structure like   section
>                          p+      there are three kinds of grouping |p|s:
> - Enclosure*           section
>                          div+
>                            p+
> - Association*         section
>                          p.foo+
>                          p.bar+
> - Separation*          section
>                          p+
>                          hr/
>                          p+
> 
> I consider the first natural, the second more flexible but weaker and 
> the third visual. For it's already there, it's pragmatic to retain the 
> option to use an empty separator. I still don't like it conceptually.

I think all are fine, but I think they are distinct in purpose.

The first separates the <p>s so that the two groups aren't closely 
related.

The second keeps the <p>s related, but each is annotated into a separate 
class.

The third keeps them related, but separates them using another paragraph 
(the <hr>).


> >>> An <hr> is equivalent to a <p> with the content "Meanwhile, 
> >>> somewhere else..." or similar (...).
> >>
> >> No, it's not. You are connecting it with the succeeding element 
> >> instance, but it's not. Anyhow, if it was, why wouldn't you use a 'p' 
> >> with that content or an empty one?
> >
> > Convenience, clarity.
> 
> In your opinion today, is |hr| in HTML5 structurally (and semantically) 
> about equivalent to an empty paragraph or to an empty heading?

It's a paragraph, but it's not empty. It's saying "meanwhile..." or 
"later..." or some such (depending on context).


> >> I, on the opposite, think that it's unnatural to mark the end of one 
> >> thing and the start of a second, but neither the start of the first 
> >> nor the end of the second. The reason you can do this in a printed 
> >> work is, that these are *implied* by chapter starts and ends. [DTD 
> >> stuff snipped]
> >
> > I think it is unrealistic to expect most authors to think this way.
> 
> Really? If we can get them to think in semantics rather than in visual 
> styles, why would it be harder for them to think in enclosure or 
> association than in separation?

It's hard enough to get them to think in semantics in the first place.


> > I disagree that hierarchy need be the way we mark things up here.
> 
> It makes styling with CSS easier, though.

I'm not at all convinced that CSS on sibling blocks is easier than <hr>.


On Thu, 13 Dec 2007, Henri Sivonen wrote:
> 
> The current outline algorithm is not stated from an implementation-friendly
> point of view. Instead of requiring each implementor to recast the algorithm
> in a different way and to investigate the feasibility of such recasting, it
> would be more helpful if the spec algorithm were stated in a more
> implementation-useful POV.
> 
> 1) There should be a statement of the algorithm as a side-effect of
> forward-only tree walk. That is, the algorithm should not own the tree walking
> loop but should instead define variables it keeps and changes to these
> variables as elements of are seen. This would allow straight-forward
> implementation as part of a sweep over the tree that is already happening for
> another reason.

Done. Let me know if it's acceptable.


> This sweep should probably define what checkpoint data to store on each 
> element that implements the HTMLHeaderElement interface to allow local 
> recomputation.

I'm not sure exactly what you had in mind here.


> 2) It would be useful to define the outline depth in a way that allows 
> local recomputation by walking from a tainted node whose outline depth 
> is to be re-evaluated to the previous untainted HTMLHeaderElement node, 
> reinitializing the algorithm variables with the checkpoint data stored 
> there and resweeping forward until the end of the parent of the tainted 
> node is reached. For this to work, the outline depth should be stated in 
> such a way that changing a node does not cause outline changes outside 
> the parent of the changed node.

It should now be possible to start from a tainted node, go back to the 
last non-tainted node in the same sectioning element or sectioning root, 
and move forward until the end of that element or the start of the first 
untained nested sectioning element, without re-outlining the inside of any 
untainted sectioning root elements.

Does that work?

I'm not sure if this is exactly the conditions you suggest. Let me know if 
the spec is ok.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'