Reconsider FAQ: <di>, <div> or <li> wrapping <dt> and <dd>

[Crissov]

Explicitly grouping dt and dd together has been proposed so often that it’s featured in the Rationale and has been in the FAQ since 2008, getting further explained in 2010.

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

There will be no CSS pseudo-element ::wrap in the forseeable future, see w3c/csswg-drafts#588. I believe it’s therefore worth to reevaluate the use cases and review the FAQ entry.

Current state

The parsing rules for dl are quite clear, but even if browsers implemented them perfectly, there’d still be no way to take advantage of the structure in CSS.

<dl>
  <dt>term <dt>alias <dd>definition
  <dt>term <dd>definition <dd>alternate definition
  <dt>term <dt>alias <dd>definition <dd>alternate definition
</dl>

di Wrapper

This has also been called dli. It has all the problems of any new element type, and some more.

<dl>
  <di><dt>term <dt>alias <dd>definition</di>
  <di><dt>term <dd>definition <dd>alternate definition</di>
  <di><dt>term <dt>alias <dd>definition <dd>alternate definition</di>
</dl>

li Wrapper

It has all the problems of using existing elements in places where they were not supposed to occur previously, which can be quite unexpected.

<dl>
  <li><dt>term <dt>alias <dd>definition</li>
  <li><dt>term <dd>definition <dd>alternate definition</li>
  <li><dt>term <dt>alias <dd>definition <dd>alternate definition</li>
</dl>

dt/dd in li

It may be worth exploring whether ditching dl has better backwards compatibility than changing it.

<ul>
  <li><dt>term <dt>alias <dd>definition</li>
  <li><dt>term <dd>definition <dd>alternate definition</li>
  <li><dt>term <dt>alias <dd>definition <dd>alternate definition</li>
</ul>

Generic list element

<list>
  <lh>header
  <dt>term <dd>definition
  <di><dt>term <dt>alias <dd>definition</di>
  <di><dt>term <dd>definition <dd>alternate definition</di>
  <di><dt>term <dt>alias <dd>definition <dd>alternate definition</di>
  <li>item
</list>

[zcorpan]

dt and dd have optional end tags, which doesn't interact well with wrapping in a new element.

Wrapping in li works fine parsing-wise, even when you omit the </dd>/</dt>/</li> tags. [doesn't work so well either parsing-wise; if you omit all end tags then the inner li gets nested in the dd instead of becoming a sibling of the previous li.] The default style would give you bullets, which doesn't seem great. Also nested lists get different style for the bullets today, but that would not work without new more complicated rules to the UA stylesheet.

How about allowing div as the wrapper? It has no problems parsing-wise (the end tag is required), it does not alter the default styling, and it seems like it has the right semantic ("represents its children").

[Crissov]

Indeed, li would work (better) if its end tag was not optional when inside dl.

DOM viewer of all variants from above and more

[domenic]

div sounds pretty great to me.

[tabatkins]

I'm 👍 to DIV. I also really like LI if it auto-closes better and gets some UA styling, but that's a lot of effort.

[Crissov]

div is better than di because the latter looks like a typo of the former and sometimes actually will be one. If it was to be a new element type, there are several possibilities, e.g. wrap, item, entry, def, desc (SVG conflict).

[annevk]

I have been wanting this for a long time. Kudos to y'all for coming up with something that might fly.

[zcorpan]

Summoning @sideshowbarker

I'm thinking we make the content model as strict and simple as possible: either dl contains only dt and dd children like today, or it contains only div children, each of which must contain exactly one (dt+, dd+) group. So empty divs not allowed, and arbitrary grouping or nested divs also not allowed.

No change to the parser, rendering, or other UA requirements; this should only affect document conformance.

[Crissov]

Spec-wise, it seems there is no way around a wrapping element with mandatory end tag. The deciding question probably is which one (new or reused) provides the best backwards compatibility:

1. <ul><li><dt>term <dd>definition</li></ul> – requires special-casing dt/dd content of li, should work the same for ol
2. <dl><li><dt>term <dd>definition</li></dl> – requires different rules for li inside dl than inside ol/ul
3. <dl><div><dt>term <dd>definition</div></dl> – only requires changes to the content model of dl, may have existing use
4. <dl><entry><dt>term <dd>definition</entry></dl> – this is di, i.e. a new wrapping element
5. <list><li><dt>term <dd>definition</li></list> – alternative for 1. or 2., if none of the above degrades gracefully; could allow other features like list headers/captions
6. <list><div><dt>term <dd>definition</div></list> – alternative for 3., otherwise like 5.
7. <list><entry><dt>term <dd>definition</entry></list> – alternative for 4., otherwise like 5.

Semantically, all variants can be argued for well enough.

[zcorpan]

I think we shouldn't mint a new element, as I said, it doesn't interact well with omitting end tags of dt/dd. So that rules out 4, 5, 6, 7. A new element instead of dl could also have other implications like regressing usability for people using accessibility tools; suddenly they can't skip over a dl element, for example.

And li didn't work well in terms of parsing and styling, so that rules out 1 and 2. Just saying that </li> is required in this context is not so helpful because tools probably exist that assume it is optional anywhere, and will just strip them out.

That leaves 3. I can't think of any practical problems with it. As far as accessibility tools go, I've quickly tested VoiceOver with Safari and ChromeVox with Chrome (both on Mac OS X), and there was no difference for 3. Since the stated problem is about styling, I think getting no difference in accessibility tools should be a goal. With li I got extra "bullet" or "list item"; a new list element affected navigation in ChromeVox.

More testing in other screen reader/browser/platform combinations is welcome, but so far I think div is most promising.

[sideshowbarker]

As far as any proposal for changing the dl content model at all, without adding any new elements, from a conformance-checker POV the main possible problem I see is the general problem that when we change or relax existing doc-conformance requirements, it may inadvertently cause authors to miss some genuine mistake the checker otherwise would have been able to help them catch.

But I think the using-an-existing-element option that would carry the least risk of that problem is the div option—if we spec the doc-conformance requirements in the way described in #1937 (comment) so that, e.g, a div that’s a child of a dl must contain exactly one (dt+, dd+) group.

Certainly it’s practical to implement the checking for that in the validator

So I like the div option.

As far as the option of instead minting a new element, from a conformance-checker POV: while it doesn’t carry the risk that I think a repurpose-an-existing-element option does of possibly causing authors to miss genuine mistakes the checker would otherwise help them catch, IMHO it’s not the right option in this case—for the same reasons @zcorpan gives but also because:

• For the sake of authors I think we should always be extremely conservative about adding new elements, and only do it when there’s a really compelling need and no other appropriate markup options to solve the problem the new element would be intended to solve.
• It seems to me in the many years during which we’ve discussed this problem/use-case, implementors have shown relatively little interest in it, and so it also seems to me that they would especially show little interest in adding a new element to solve the problem. And of course we can’t end up getting implementor support for it, we will have just been wasting our time.

[zcorpan]

I've prepared a PR for spec change at #1945
Test cases for conformance checkers at web-platform-tests/wpt#4053