Day 63 of 100DaysOfSpec, the address element and document outlines

I am reading and taking notes on the HTML specifications for 100 days as part of #The100DayProject. Read the initial intent/backstory. I am a Microsoft employee but all opinions, comments, etc on this site are my own. I do not speak on behalf of my employer, and thus no comments should be taken as representative of Microsoft's official opinion of the spec. Subsections not listed below were read without comment.

Currently reading in 4.3 Sections

UAs = user agents = browsers and other HTML document parsers/renderers

4.3.9 The address element

“The address element represents the contact information for its nearest article or body element ancestor.”

• You can’t just use this element willy-nilly for anything that resembles an address (here’s all our offices blah blah), it has to be relevant contact information for the content on the page/in the article.
• You can’t stuff other content into an address that otherwise contains proper contact info (like a “last modified” date).
• The reason why you have those content restrictions is that the UA is permitted to expose this info to the user somewhere in the UI besides where your HTML document has been rendered. For example, right-clicking on a page and seeing contact info in a “more info” pane.
• “Typically, the address element would be included along with other information in a footer element.”
• Lots of restrictions for this element’s content model: “Flow content, but with no heading content descendants, no sectioning content descendants, and no header, footer, or address element descendants.”
• Only allowed ARIA role is contentinfo. That’s not the default value, which is sort of odd and the first time I’ve seen that so far (only one available, no default).

4.3.10 Headings and sections

This section goes a little more into the semantics of headings and sections and how those are used to create page outlines.

Makes sense to just paste the first bit on semantics: “The first element of heading content in an element of sectioning content represents the heading for that section. Subsequent headings of equal or higher rank start new (implied) sections, headings of lower rank start implied subsections that are part of the previous one.”

blockquote, body, fieldset, figure, td:

• are considered sectioning roots
• can have their own outlines
• their outlines do not contribute to their ancestors’ outlines

“Sectioning content elements are always considered subsections of their nearest ancestor sectioning root or their nearest ancestor element of sectioning content…” Sigh, I’m just copy-pasting everything today…I would also take a look at the code example they have there in the spec to demonstrate the principles listed above.

For all this talk of semantics, the spec encourages devs to wrap sections with sectioning content elements, rather than rely on heading elements’ creation of implicit sections. Wonder if this is simply a coding style preference or seated in some real-world problem that comes with not using sectioning content elements.

4.3.10.1 Creating an outline

We can’t rely on the outline algorithm yet for expressing document structure to the users. Conformance checkers have implemented this algorithm, but no “graphical browsers or assistive technology user agents”.

Anyway, this algorithm creates an outline for a sectioning content or sectioning root element by looking through nodes in a DOM tree.

• An outline has 1+ nested sections that correspond to DOM tree nodes. Each of these can have a heading and its own nested subsections.
• This algorithm is the correct one to use when creating document outlines, like a ToC. If that ToC is interactive, the user should be jumped to whichever element node was used to create the section in the outline. However, navigating to the first outline section should always just take the user to the top of the document, even if there’s content preceding the first heading.
• The body element outline == the document’s outline.