Can <header> represent headers in sectioning elements?

[diegosolo]

Hi! As far as I can remember, <header> could be used in articles as well as in the body of a document. Currently there's no reference about it in the element's description, so I assume this is no longer a suggested use.

If that's the case, there's an example in "4.3.12 Usage summary" that shows the element inside an <article>, clearly being used to enclose header information for it.

In any case, I think it would be better if this is made clear in the description of the element, as it is in the description of <footer>, for example.

[domenic]

This seems pretty clearly encouraged from the description. I don't think we explicitly need to call out every tag you can use header in.

In any case, I think it would be better if this is made clear in the description of the element, as it is in the description of <footer>, for example.

Where do you see that? There's an example, but no list of all elements you can use footers in. And again, I don't think we should have an example for every element that a footer or header could be in.

[domenic]

I guess we do have a "list" of all places the element can be used:

Contexts in which this element can be used: Where flow content is expected.

Then if you check the content model for article, it says:

Content model: Flow content.

So this is pretty clearly spelled out in the spec already I guess.

[diegosolo]

Sorry, my mistake!

[diegosolo]

Sorry, I think I messed everything up yesterday. What I actually meant to say was this:

In <footer>'s description, I can see clearly that the element can be used to represent a footer for the document, as well as for any section it's child of (not just an <article>... my bad).

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element.

In <header>'s description this isn't that straightforward. It gets implied in the note:

A header element is intended to usually contain the section's heading (an h1–h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section's table of contents, a search form, or any relevant logos.

But here, the focus is placed in what it can contain, and I think it could be more helpful if it's just there in the description, leaving no doubts. Also, saying it can be child of a section isn't the same as saying it can represent its header.

Am I right?

[domenic]

I don't believe this is correct. Although it's often used for sections, it can also be used for many other things, not just sectioning contents or sectioning roots.

[diegosolo]

I see. Further reading arouses more doubts.

Regarding sections, this statement would be true if you don't allow <header> to represent a header for an implied section. But other elements, like <footer> or sectioning content elements don't consider implied sections. Besides the case of <footer>, already cited in my previous message, sectioning content elements don't:

Sectioning content elements are always considered subsections of their nearest ancestor sectioning root or their nearest ancestor element of sectioning content, whichever is nearest, regardless of what implied sections other headings may have created.

As stated in 4.3.11 Headings and sections. As far as this goes I don't see an immediate reason for <header> to behave differently.

But I assume from your answer that you're talking about yet other elements. Any idea which ones? Or should it be left deliberately open to support other cases? In any case, I think it would be good to make it clear in the description.

Thank you!

[sideshowbarker]

Or should it be left deliberately open to support other cases?

That is the effect (and intent) of the current definition for header, which just says this:

The header element represents a group of introductory or navigational aids.

And the corresponding definition for footer cited earlier in this issue, is this:

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element.

It is intentional that the definition for header doesn’t mention sectioning content or sectioning root elements or any other classes of elements or any other specific elements. It’s not an oversight.

In any case, I think it would be good to make it clear in the description.

IMHO the current definition for header already makes clear that header supports any use cases for marking up a group of introductory or navigational aids. The definition explicitly says that’s what it’s for, and that is an intentionally broad, open-ended definition. I don’t see how adding anything that frames the definition in terms of other elements is going to to make it any more clear.

As far as what such an addition to the current language would even look like, the only thing I can imagine is something like:

The header element represents a group of introductory or navigational aids, with no particular restrictions on what other elements in the document are associated with the group of introductory or navigational aids the header provides.

But to me that doesn’t really make the definition any more clear. So if you have other concrete language in mind that’s more like what you think should be added, I guess it would be useful to post a comment here providing the specific language.

[diegosolo]

I see, thanks for clarifying. I don't feel it's my decision to make, but as a content author, the description as is, aroused doubts about how to proceed using the element. Reading down to <footer> I assumed (wrongly) it would represent header information for its nearest ancestor sectioning content or sectioning root element. Clearly, if I place it inside an <article> it represents a group of introductory or navigational aids for that <article> (right?). Plus, searching through the W3C's HTML5 Recommendation, HTML5.1 Recommendation and HTML5.2 Editor's Draft I found that same behavior. I read the FAQs and I know it shouldn't matter what W3C Specifications say, but adding all factors, it simply helped making sense to assume that the description here was missing something.

Summing up, with the description as it is, I 'd have doubts on where it would be "proper" to place the element and if its contents should represent a group of introductory or navigational aids for any of its ancestors, for the whole document or just represent a group of introductory or navigational aids (for no one particularly).

Following your proposal:

The header element represents a group of introductory or navigational aids, with no particular restrictions on what other elements in the document are associated with the group of introductory or navigational aids the header provides.

Would the header inside, for example, an <article> represent a group of introductory or navigational aids for its parent?

[sideshowbarker]

Would the header inside, for example, an <article> represent a group of introductory or navigational aids for its parent?

It might be a group of introductory or navigational aids specific to the article itself, but probably more typically it would be a group of introductory or navigational aids associated with the site the document is found in—say, a shared header that’s common to every document in the (sub)site and that exists on the server side as a separate resource/file that gets included by reference at the top of every document.

[stevefaulkner]

It may be helpful to understand how the semantics of header/footer are expressed in the aural UI and defined for browser implementers in the HTML Accessibility API Mappings spec. This spec is normatively referenced by both w3c and whatwg html.

header (descendant of body but not of main or other sectioning content or sectioning root element)

is exposed with a banner landmark role

header (descendant of main or of a sectioning content or sectioning root element other than body)

is exposed with a group role

The same implementation rulles apply to footer.

What this means in practice is that the header and footer elements are only conveyed to users by default (and as landmarks) when they are scoped to the body element. In other circumstances their (group) semantics are not convyed unless the element has an explicit accessible name (via aria-label/aria-labelledby).

[diegosolo]

After going through this discussion, I understand better the role that <header> has in a document. But, although it may seem trivial, I suppose other people (specially authors like me) would benefit from the expanded explanation suggested in @sideshowbarker's first answer. When I first read the current description I had many doubts about how, where or for which element I could/should use <header>. I leave it for your consideration.

Thank you!

[patrickdark]

I think the spec could a bit more expansive on describing use cases. There are three header examples right now and they all apply to the document body.

One use case I've found is to mark table heading cells with header and main and use the header element to place <a rel="bookmark"> icon links. This neatly separates content from non-content.

For all types of table cells and list items, I use footer to mark footnotes. I notice that footnotes are not explicitly mentioned in the list in the first description paragraph.

This should have the same effect, though I now notice that footer is scoped to a sectioning element, not its parent element...

[diegosolo]

For tables you have other more specific grouping elements like thead, tfoot and tbody. I don't believe you should use footer for a table's footnote (as a table is not a sectioning element) but a different thing goes on with header: as it is, it could define a group of introductory or navigational aids for a table; all depends on what you put inside of it.

As I have already left clear, I very much agree with you on this:

I think the spec could a bit more expansive on describing use cases. There are three header examples right now and they all apply to the document body.

[patrickdark]

@diegosolo I'm using cell headers and cell footers as shown in the following image, not table footers.

The header element contains bookmark links that are floated to the top-right and visible on hover as shown in the lower-left cell. Those would seem to qualify as "navigational aids". See https://html.spec.whatwg.org/multipage/semantics.html#the-header-element.

Not sure what to use for the footnotes. footer seems the most appropriate, but applies to the section holding the whole table for the th elements and to the cell itself for the td elements since those are "sectioning roots", which doesn't make a whole lot of sense. See https://html.spec.whatwg.org/multipage/semantics.html#the-footer-element.

I suppose aside might be more appropriate than footer, though it has the same problem since it likewise participates in the outline model; it behaves differently depending on whether or not the ancestor cell is a th or td element. See https://html.spec.whatwg.org/multipage/semantics.html#the-aside-element.

Seems like the outline model is broken and interfering with choosing the most appropriate element. Which means I'm probably going to just end up ignoring that model and sticking with footer.

[domenic]

Seems like the outline model is broken and interfering with choosing the most appropriate element. Which means I'm probably going to just end up ignoring that model and sticking with footer.

This isn't really a correct way of looking at things. The outline model defines when elements are appropriate. If your markup is generating an unintended outline, you should really use <div class="footer"> instead of <footer>, or similar, since you're intentionally looking for something without the semantics of a footer.

[patrickdark]

@domenic This content is a footer, just not a footer of the element to which HTML outlining model assigns the footer. I'm inclined to believe the outline model is at fault here as it clearly seems to be in another issue I filed at https://github.com/whatwg/html/issues/2447 regarding the details element.

As for alternatives, there doesn't appear to be an element for "a thing not representable in HTML".

I was looking at things as if there were until I got into a dispute over whether we should have dgroup or div to wrap dt and dd elements. Apparently, div is essentially a transparent element for the purposes of the spec. Which means that using div is semantically identical to just placing the footnotes directly into the cell, even though this is what you might call "out of flow" content (for lack of a term) that isn't directly a part of the cell data. In other words, if I add or strip a div element, the meaning doesn't change because "it represents its children", not itself, so that suggestion doesn't solve any problems.

So the solutions are (A) don't use this paradigm; (B) ignore the spec; or (C) change the spec. I think the footer outline issue would be fixed if it was rooted at its nearest non-div ancestor instead of the nearest sectioning element. That would neatly solve this issue and confer on the element a lot more utility. Either that or create yet another footer element named something like notes that's likewise rooted at a semantically meaningful ancestor.

[stevefaulkner]

Seems like the outline model is broken and interfering with choosing the most appropriate element. >Which means I'm probably going to just end up ignoring that model and sticking with footer.

The outline model is broken and unimplemented, it has no practical effect upon user experience, so ignoring it's theoretical effects is acceptable. In terms of your use of <footer>'s practical semantics, i.e. implemented meaning actually conveyed to users, it has the semantics of a landmark role=contentinfo when scoped to the body element, otherwise it is a generic grouping element. Same deal for <header>.

[patrickdark]

@stevefaulkner So there's apparently a role="note" for this in WAI-ARIA 1.1 at https://w3c.github.io/aria/aria/aria.html#note.

<th>
    <main aria-describedby="song.note.a song.note.b"><cite>song title</cite></main>
    <p id="song.note.a" role="note">note</p>
    <p id="song.note.b" role="note">note</p>
</th>

Pretty ugly since there's no implicit association defined so an ID reference is needed, but it gets around the outlining model's limitations. Still seems like it'd be better to have a dedicated note element or fix footer (and gloss over the content being specifically notes).

[stevefaulkner]

@patrickdark role=note works, but is not well supported by AT. The use of main in your example is a complete misuse, in my opinion which is why we define it quite differently in the W3C HTML spec :-) refer to https://github.com/whatwg/html/issues/100 , as the WHATWG HTML definition of main encourages overuse, which has negative effects upon users who consume the semantics of main and reduces the utility of its meaning.

th is exposed in the aural UI as either a column header or row header, its content should be a brief description/title for the col/row, it should not contain paragraphs of text. Use of aria-describedby in this context is unnecessary and duplicates the content of the element., thus the text exposed via accessibility API's to AT as a result of the accessible name calculation is "song title song title". I suggest that the appropriate, practically semantic markup for you example is something more like:

<tr>
<th>
<cite>song title</cite>
</th>
<tr>
<tr>
<td>
<div role="group" aria-label="Notes">
 <p id="song.note.a">note</p>
<p id="song.note.b">note</p>
</div>
</td>
<tr>

[diegosolo]

I'm using cell headers and cell footers as shown in the following image, not table footers.

Sorry, didn't get that. Is it possible, then, to use a section element as container for all the cell data? td content model consists of flow elements, which includes section, yet I'm not sure if it would be a proper use of section:

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading

There's also article, if the cell's content classifies as:

a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication.

Being td a sectioning root this shouldn't affect the outline of your document.

[patrickdark]

@stevefaulkner Thanks. That ARIA structure seems like a good idea. I'll probably implement that.

The aural information is useful. I'd imagine AT reading out "note:" before every note, so this seems to be on the right track. It's too bad there isn't a clear guide (or free browser) to determine these things.

I don't expect to separate the notes from the table headings into a separate table data cell though. That isn't sufficiently compact enough for visual users and there isn't justification for it given the handful of notes in what is currently 386 rows (i.e., songs).

@diegosolo section participates in the document outline so I think it'd have the same problem as aside. In a hypothetical outline, you should see two sections beneath the table heading, which doesn't make much sense. Even less so since the td element notes would not have any subordinate sections because they're "sectioning roots".

I can't see notes being useful for syndication, so article is out of the question.

[diegosolo]

In a hypothetical outline, you should see two sections beneath the table heading, which doesn't make much sense.

I don't think it should:

Certain elements are said to be sectioning roots, including blockquote and td elements. These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors.

[patrickdark]

@diegosolo I was referring to the th element. It's true that the outline would correct would be correct for td elements if I used section elements, but I want to use this note convention for both th and td cells, which have different outlining behaviors.