+++ This bug was initially created as a clone of Bug #20740 +++

I think it's fairly clear at this point that there is a painful gulf between how the spec describes document outlining and how authors in the real world are actually building web pages. Luke Steven's many posts on this topic (whether one agrees with him on all points or not) are a visible symptom of this situation. Most recently check out (including comments):

http://www.webdesignerdepot.com/2013/01/the-harsh-truth-about-html5s-structural-semantics-part-1/
http://www.webdesignerdepot.com/2013/01/the-harsh-truth-about-html5s-structural-semantics-part-2/
http://www.webdesignerdepot.com/2013/01/the-harsh-truth-about-html5s-structural-semantics-part-3/

Given the "at-risk" status of the outline algorithm, I think something's got to give here. (Stevens, unfortunately, has no constructive suggestions about outlining proper, which strikes me as somewhat defeatist.)

I definitely don't have all the answers, but having watched this evolve from the sidelines for years, I think there are some things that could be done to nudge the spec and real-world practice towards a greater state of parity and clarity. Here are a couple modest proposals:

1) Rename the terms "sectioning content", "sectioning root", and "section" in the spec. Here's the problem: the terminological overlap between the terms "sectioning content" (used to refer to content that defines scope of headings and footers, for example article, aside, nag, and section) and the term "section" (used to refer to the <section> element) is deeply confusing. The reuse of the same noun (or is the former sometimes a gerund?) in two very different but conceptually adjacent contexts is compounding the overall mess here.

The clarification in HTML 5.1 Nightly "4.4.11.1 Creating An Outline" that says: "The sections in the outline aren't section elements, though some may correspond to such elements — they are merely conceptual sections" doesn't really do much to clarify things. What, pray tell, is a "conceptual section"? In philosophy (and also typically in technical writing), a "concept" is something that has a "definition". It's distinct from a "notion," for example, which may not have a definition. But since all the key terms in the spec have definitions, the adjective "conceptual" provides no meaningful qualification. Try explaining to a first year web design student the difference between "sections" and "conceptual sections"!

For a technical specification, this is unacceptably confusing. I'm sure the English language is large enough that the W3C can find two suitably different terms for two different concepts. Here's my stab at a remapping of terms within the spec:

"sectioning content" = > "outlining content"
"sectioning root" => "outlining root"
"section" (not the element) => "outline container"
<section> (the element) stays the same.

Since the main purpose of "section" (again, not the element) in the spec is outlining, why not spell this out explicitly, and sidestep a bit of confusion in the process? I think this would be a win on all sides for clarity in the spec, which has been justly criticized on this point.

2) Introduce unnumbered headers, e.g. an <h> element.

By way of comparison, every beginning web developer instantly "gets" the idea of the un-numbered <li> tag. It has the great and obvious virtue that scripts can add or subtract elements from an unordered list dynamically without renumbering each element in the entire list in markup. Wouldn't it be great if headings and document outlining had the same flexibility?

As you know, the spec's current suggestion is to use all <h1> tags: "Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level." The idea was to avoid introducing new elements, and maintain backwards compatibility.

This spares browsers' parsers the relatively trivial task of recognizing a new block element, but it introduces massive confusion for any implementation of document outlining. Predictably, there has been chaos. For any particularly page, is a screen reader (for example) supposed to use the new HTML5 outlining algorithm or the old? And based on what factors? There are no good answers here that I know of, not even provisional ones. No wonder vendors have dragged their feet on this! The "all h1, all the time" approach tries to split the difference between two completely different ideas about page structure, and winds up totally breaking the old outlining model without providing a satisfactory indication that the new model is in use on the page. This offers neither enhancement nor degradation--it's pure breakage, and it's not suited to the backwards-compatible, incrementalist approach that the web requires.

Instead, the "one h element to bind them all"  approach needs to be taken to its logical conclusion, making a clean break with the old outline model, and forging a very clear path toward the new "section" (renamed, please!) based outlining model, which has real virtues that should not be simply shelved for lack of implementation so far. The advantages of this unnumbered <h> tag approach are:

1) Nearly total backwards compatibility. Existing popular HTML5 javascript shims could very easily be tweaked to include an unnumbered <h> element.
2) No styling issues. Authors just use classes for styling. Personally, the idea of adding class names to my <h> tags to style them doesn't bother me in the least. (I disagree with Luke Stevens on this point). Similarly, Hickson's idea that adding a single class to an element is somehow "hard" for developers doesn't resonate with me.
3) Lucid developer aesthetics. Developers have it hammered home that the place of the <h> within the outline is determined by context, just like an <li> element. It's easy to learn, it's simple to type, and it's meaningfully contextualized.
4) A clear criterion for HTML5 outline interpretation in user agents. User agents can be advised to switch their outlining based on the presence of unnumbered <h> tags in the markup. It could be as simple as: "If there's a single <h> on the page, do it the new way. If there aren't any, do it the old way." With this more backwards-compatible implementation path, we might succeed in getting some implementations. :) Some developer evangelism would still naturally be required.

Thanks for reading.