Disallowing aside within dt is overly prescriptive

[tabatkins]

The definition of the dt element disallows, among other things, sectioning content.

In general, this is probably a good move - it doesn't make a lot of sense to have section inside of what is meant to be a definition term. Why is the dt that complex?

But there's one exception that I think should be reconsidered - aside should be allowed in dt (and other places where sectioning content is disallowed?).

If you think in terms of inline content, the aside restriction makes just as much sense as the section restriction - dts shouldn't be that complex. But aside has a useful semantic that can be applied to non-inline content as well, associating some positioned or hidden content with the dt while still correctly asserting that it is not part of the semantic meaning of the dt.

For example, see https://github.com/whatwg/wattsi/issues/129 and https://github.com/tabatkins/bikeshed/pull/1727, where a dt in a spec can contain a dfn (very reasonable), which can have a "dfn panel" associated with it, which is hidden by default and floats to the side when expanded, to give more information about the usage of that definition across the document. The dfn panel is definitely not part of the semantic flow of the dt (it shouldn't be read out alongside the definition), but it's reasonable and probably most correct to have it still closely associated with the definition it's summarizing (not to mention the CSS-positioning issues, which are much easier to resolve if the panel is next to the dfn in the source).

As @sideshowbarker said in https://github.com/whatwg/wattsi/issues/129:

So it’s not clear to me what problem we are trying to help avoid authors/developers avoid by making aside within dt non-conforming. Unless it’s clear to others what the problem is, then I suggest we consider dropping that restriction.

I suggest we rejigger the definitions a bit to allow aside to be used fairly broadly, and not be restricted by "sectioning content" restrictions that (reasonably) disallow the rest of the sectioning elements.

[domenic]

I tend to disagree. You shouldn't have asides on your definition terms. You can have asides about the data, but why would the terms need

a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content.

?

Note

Such sections are often represented as sidebars in printed typography.

Again, a sidebar makes sense on a longer term definition. But a sidebar on the term itself? Typographically it would be silly; it'd stretch out the term too far.

[tabatkins]

You're participating in the linked issues, so you know exactly why you would - because the dfn panel is about the defining term itself, not the explanatory definition. For example, if you had two terms that shared a dd (because their definitions are related), each would have their own dfn panel.

And typographically it's just fine, again as you are already aware of, because all WHATWG and most W3C specs use asides in exactly this way already. They're not literally in the sidebar, but rather initially-hidden floating panels that can be shown or dismissed as needed; in interactive media this is a completely reasonable and legitimate variation of "sidebar".

[sideshowbarker]

But aside has a useful semantic that can be applied to non-inline content as well, associating some positioned or hidden content with the dt while still correctly asserting that it is not part of the semantic meaning of the dt.

I think that’s a key point.

I believe it’s also important to decouple/ignore the presentational consideration/assumptions about the effects that having an aside within a dt will have on page layout. Those are rightly just considerations for developers to deal with themselves, in whatever ways they choose to deal with them.

I think the strongest argument for allowing aside within dt is this:

Off the web, in printed books (or journal articles, or whatever), where footnotes or endnotes are the typical way for authors to add annotations, there are zero restrictions on what particular parts of the text an author might choose to annotate with a footnote/endnote indicator.

So if there are no such restrictions for authors of printed books, why should we place restrictions on web authors?

Why restrict authors of web content from being able to do something they could do just fine if they were authoring/presenting the same content as a printed book?

In particular, if a printed book contains some associative list of terms and definitions (that is, the equivalent of a dl/dt/dd list), it’d be perfectly reasonable to see an author adding a footnote indicator to one of the terms in the list — rather than to the definition of the term.

We wouldn’t find it odd at all if a book/journal author added a footnote indicator to a term in a list like that. And it’s easy to imagine reasons why an author might want to do that. For example, maybe the footnote is some aside about a particular aspect of the term itself — the etymology of the term, or a comment that the term has pejorative connotations, or whatever.

It’s completely up to the author themself: (1) to choose to “aside” the information into a footnote to begin with (rather than in the main text flow), and (2) to decide where they prefer to place the footnote indicator (that is, on the term itself — if they think that’s the place where they want to alert readers to it — rather than at the end of the definition which follows the term).

[domenic]

I guess I'm convinced. These types of asides are indeed related to the term, not the definition/data of the term.

I wonder how this contributes to the outline stuff. Maybe dt should become a sectioning root? I.e. "These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors."

[tabatkins]

Just to be clear, I don't think they should become sectioning roots in general - I think it's still reasonable to disallow section/etc in a dt. aside just occupies a slightly different role than the rest of the sectioning elements.

[scottaohara]

I've read through the linked issues here, and I'm still not sure I understand the need for this allowance? (this ended up being a bit long. so thank you in advance for baring with me here.)

Consider the following markup:

<dl>
  <dt><aside>term</aside></dt>
  <dd>description for term</dd>
</dl>

This seems odd, as the term would be marked as tangential to the description. but being in a key/value list like this, I wouldn't ever think the dt to be tangential.

The previous/current allowance of aside within dd also seemed strange, at first. I wondered why the entire dl wasn't just wrapped in an aside? However, I suppose it could be useful for when a term has more than one description, where there's a preferred description and then additional ones are tangential to the first. Still a bit awkward considering the accessibility mappings for aside. But more on that in a bit...

Per this thread, allowing aside in both dt and dd, as in the following snippet, are the term and description tangential to each other? That doesn't seem right in a key/value pairing.

<dl>
  <dt><aside>term</aside></dt>
  <dd><aside>description for term</aside></dd>
</dl>

I wonder if rather than allowing dt to contain aside, it would instead make sense to allow the dl to contain aside, like a dl can contain a div.

<dl>
  <dt>term 1</dt>
  <dd>desc 1</dd>

  <!-- key/value stay related -->
  <aside>
    <dt>term 2</dt>
    <dd>desc 2</dt>
  </aside>
</dl>

The other part to all of this is how aside is presently mapped and exposed to the accessibility tree in browsers. Each instance of an aside creates a "complementary" landmark. So someone using assistive technology, navigating by landmarks, would come across an aside within a dt and also a dd, would first find a complementary landmark containing the "term", and then a second containing the description. This would be both unexpected and increase the verbosity of interacting with this content. It'd be more expected for the key/value pairing to be exposed in a single landmark... however, the worry about an abundance of complementary landmarks would still remain if this was a common pattern used on a page. The more things that are called out as being important, the less important they each become.

I'm honestly wondering if an aside needs to be treated like header and footer, where they're only exposed as landmarks if scoped to the body element. This would allow for aside to be used more loosely as discussed in this thread...but then, as far as accessibility mappings are concerned, it becomes yet another generic element that provides no useful meaning to actual users.

So, all that said, I hope it will help in making a decision in how this issue will end up be resolved.

[sideshowbarker]

Consider the following markup:

<dl>
  <dt><aside>term</aside></dt>
  <dd>description for term</dd>
</dl>

That case is different from what’s been discussed here, which is instead like this:

<dl>
  <dt>term <aside>foo bar baz</aside></dt>
  <dd>description for term</dd>
</dl>

… where foo bar baz is content of some popup or footnote, etc., related to term

[scottaohara]

thank you @sideshowbarker. I'm sorry that was unclear to me on my initial read through.

my comments about a less than useful complementary landmark being exposed containing only a short phrase of text is still unfortunately valid to that use case though.

[tabatkins]

The alternative to that, tho, is either

(a) no landmark at all, the unrelated text just being read directly as part of the term (and semantically attached to the term)

(b) an aside placed elsewhere, then dodgy JS used to position it next to the dt; if things move around and the JS isn't written exactly right, it then doesn't make any sense to anyone, landmark-user or not.

[stevefaulkner]

I'm honestly wondering if an aside needs to be treated like header and footer, where they're only exposed as landmarks if scoped to the body element. This would allow for aside to be used more loosely as discussed in this thread...but then, as far as accessibility mappings are concerned, it becomes yet another generic element that provides no useful meaning to actual users.

Agree, if it is allowed to be used as described in this thread we will need to limit the default implicit semantics for aside. Wondering who will benefit from the semantics other than developers in this case.