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

[inoas]

I'd prefer <di> or <dg> (definition group) to <div>, but latter works especially as it does probably need lots less implementation changes.

[stevefaulkner]

On 21 October 2016 at 11:20, Simon Pieters notifications@github.com wrote:

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

the

element is 'semantically neutral' as far as AT are concerned.
they are ignored, except in some cases where they are descendants of ARIA
composite user interface widgets. These roles typically act as containers
that manage other, contained widgets.

Regards

SteveF
Current Standards Work @w3c
http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

[zcorpan]

Thanks @stevefaulkner!

[fantasai]

Having thought about the options presented here, I think going with <div> is a bad idea and we should instead consider one of the other alternatives (re-using <li> and requiring its end tag in this case, or minting a new element such as dg). The main reason why is that the <dl> element, like some other elements in HTML (<ol>/<ul>, <table>, <ruby>, etc.), has a fixed structure. Generally, you can't just put some other random element, not even the very bland <div>, inside such structures. Here you're proposing to allow that, but in a very special way. It becomes, instead of a block-level flow element, an element that participates in and requires a very specific markup structure.

I've no doubt that you can make this work on the implementation side, but I think it would be very confusing to authors. If I can use <div> as a grouping element here, why not elsewhere? The <div> element takes any content elsewhere, so I can put paragraphs and other stuff directly inside, right?

The <div> and <span> elements are used for freely-structured flow content. Reusing them here, in a strictly structured context, is going to confuse things, as it's no longer clear whether the definition list remains strictly structured or we are introducing flowiness by introducing this supremely flowy element.

Furthermore we'd be establishing a precedent of using <div> wherever structured markup exists and needs another element. I don't think we want to establish this precedent. Certainly it doesn't exist in HTML yet, and I'd like to see a much stronger argument that this pattern of structured-markup <div> reuse ought to exist if we're to introduce it.

As for “implementors have shown relatively little interest in it”--adding a new tag that has no particular behavior is not an interesting problem implementation-wise, and Hixie was adamant about not adding a definition-group element to the spec, so this is hardly indicative of anything.

[zcorpan]

Thank you for bringing a concrete downside of div to the table @fantasai. I believe you are right that it can cause some author confusion, but I think it's not that bad as to be a showstopper. This is a judgement call; is the different content model in different contexts too confusing, or is unpredictable DOM structure a worse problem? I think we have enough experience about unpredictable DOM structure to say that it is a real problem that we should avoid if we can. As for different content models in different contexts, there is some precedent for that in HTML already.

• head requires a title child, except not in an iframe srcdoc document.
• time has different content model depending on whether the datetime attribute is present.
• iframe has different content model in HTML vs XHTML
• video and audio have different content model depending on whether the src attribute is present.
• colgroup has different content model depending on whether the span attribute is present.
• option has different content model depending on the value attribute and depending on whether the parent is a datalist element.
• menu has different content model depending on the type attribute.
• script has different content model depending on the src and type attributes.
• noscript has different content model in head vs not in head.

I have not seen examples of confusion due to the above though.

Then on the argument that this would set a "bad" precedent and future cases will also reuse div, I don't think that is something to worry about. We need to reuse an element here mainly to avoid HTML parsing problems when end tags are omitted. There are a limited set of strict-structure elements that have children with optional end tags.

• ol, ul, menu: I don't think there will ever be a reason to add a new wrapping element for these.
• ruby: went from text+rt+rp to more complex with "new" elements, which required parser changes (which are not yet implemented in Edge, I believe?). This probably suffers from unpredictable DOM structure in browsers that don't yet implement the new parsing rules. I don't know how much of a problem that is in practice, but ruby is relatively rare and complex ruby more so, and using script to walk the DOM structure of complex ruby seems like an extremely rare use case...
• select, table: we can't add any new element here in a way that works in existing implementations.

That's it, as far as I can tell. For other elements, say video, if we need a new element to wrap trackelements, there is no reason not to mint a new element for that.

[inoas]

<div> is certainly not a good choice.

I do think that <dg> or <di> have a meaning that can also be useful for semantic analysis, e.g. visually impaired / screenreaders and search engines where as <div> is meaningless. So bundling multiple <dt> and/or <dd> in groups or items makes a lot of sense. Just from that perspective <li> would also work, however <div> clearly doesn't do the job.

[zcorpan]

The element here should be meaningless. The semantics are identical with or without the wrapper element. The PR has an algorithm for doing semantic analysis of a dl element (i.e. to get the name-value groups). So as far as that aspect goes, div is a good choice in my opinion.

[inoas]

Personally, I don't see the point of adding more meaningless elements.

If styling/selecting is an issue this should be resolved by (improvements to) css selectors.

If it makes sense to add a meaningful element to group def-titles and def-descs, and it does, and by doing so you make it easier to select things for styling, then all the better.

[zcorpan]

It appears that you are missing context @inoas; I suggest you read the original post again and follow the links.

[zcorpan]

For completeness, styling is not the only benefit from allowing a wrapper element; also:

• Making it more convenient to apply global attributes (lang, title, etc) that apply to all dt and dd elements in a group.
• Making it more convenient to use microdata attributes in a dl -- without a wrapper element it is non-obvious and cumbersome to mark up microdata when each name-value group is an item with properties in different elements. See 2807854

[inoas]

I read the opening post again, including the discussion in the Rationale.

After reading I still think that:

1. For styling purposes the grouping should be achieved through CSS (or even JS). If changes to the semantic model of html allow for easier styling, that's good!
2. Semantics of microdata are IMHO weaker than true html elements. They are also harder to learn and remember.
3. Supporting <li> or <di> or <dg> would cover all:
   • html-tag based semantics
   • microdata based semantics
   • ease of selecting for styling

I read about the drawbacks of self-closing <dd>s and <di> messing them up.

 <dl>
  <di>
   <dt>a
   <dd>b
  </di>
  <di>
   <dt>c
   <dd>d
  </di>
 </dl>

This looks like it should work, but right now it gets parsed as:

 <dl>
  <di>
   <dt>a</dt>
   <dd>b
    <di>
     <dt>c</dt>
     <dd>d</dd>
    </di>
   </dd>
  </di>
 </dl>

Wouldn't this...:

<dl>
  <div>
    <dt>a
    <dd>b
  </div>
  <div>
    <dt>c
    <dd>d
  </div>
</dl>

Result into that as well?:

<dl>
  <div>
    <dt>a</dt>
    <dd>b
     <div>
       <dt>c</dt>
       <dd>d</dd>
     </div>
    </dd>
  </div>
</dl>

But my stance is that some things just take time and once vendors implement semantic grouping support, then after some time you can start using it.

[zcorpan]

For styling purposes the grouping should be achieved through CSS (or even JS).

That has been WHATWG's stance as well, until it became clear that CSS will not support this, as stated in OP:

There will be no CSS pseudo-element ::wrap in the forseeable future, see w3c/csswg-drafts#588.

.

Wouldn't this...: Result into that as well?:

No, it does not, see this link from @Crissov's comment above

DOM viewer of all variants from above and more

.

But my stance is that some things just take time and once vendors implement semantic grouping support, then after some time you can start using it.

It doesn't have to be that way, though; div requires exactly zero change in browsers and can therefore be used already. Having to wait for browser changes (that they may or may not be interested in making in the first place) does not seem like a good thing in itself.

[inoas]

Well if it is backwards compatible anyway I personally don't see a reason not to allow <div> for grouping. However I still think that at the same time it should be decided to add li or dg or di support. It will just take time for vendors and users to update their software. After all any of those tags is better for common authors than a meaningless div.

[TiddoLangerak]

Naive question: why would <div> be allowed to group <dt> and <dd>, but not other strictly structured elements, like <li> or <tr>? Wouldn't it make sense to generalize this behaviour and allow <div> to wrap anything?

[zcorpan]

I think it does, but OK. If we did change li to act like div like you suggested, what is the semantic difference of the dl? Are the name-value groups different?

[ianthedev]

@zcorpan The name-value groups themselves are not and should not be different. It the question of whether the wrapper element is used appropriately or not.

[zcorpan]

The name-value groups themselves are not and should not be different.

Then there is no change in semantics.

It the question of whether the wrapper element is used appropriately or not.

It is up to the spec itself to define what is appropriate use of an element. The appropriate use of the wrapper element in dl would be exactly the same regardless of what the tag name is, no?

[ianthedev]

@zcorpan

Then there is no change in semantics.

Using div is not semantic and using li is. Therefore there is of course a change in semantics.

It is up to the spec itself to define what is appropriate use of an element. The appropriate use of the wrapper element in dl would be exactly the same regardless of what the tag name is, no?

I meant to say that it is the question of whether the wrapper element is used semantically or not.

[zcorpan]

You have still failed to explain what the difference would be.

There are at least 4 problems that would need to changes in all browsers before li could be allowed. You can work on those problems if you wish, but I think we are not going to get any further by discussing the word "semantics" in this thread.

[ianthedev]

@zcorpan As some other commenters and I had reiterated multiple times, the difference would be our HTML becomes more semantic by using li rather than using div as the wrapper in dl.

I agree that we are not going to get any further if people in authority have no desire to address the 4 problems.

[domenic]

It appears that you are using a different definition of semantics than the HTML spec (or indeed, any HTML spec) has ever done. Your definition of semantics appears to have something to do with tag names, but that's not what semantics are about. I'd suggest carefully reconsidering and re-reading the appropriate specification sections. If you disagree with the meaning of semantics in HTML, that's fine, but that's an argument for not using HTML and instead using a different language; we're not going to change the meaning of semantics in HTML according to your notion.

[ianthedev]

@domenic Thanks for your concern. I'm not using a different definition of semantics than the HTML spec. And I know semantics is not necessarily linked with tag names.

[inoas]

There are still two issues being discussed here IMHO, one is perfectly summed up by @Hixie's comment:

The real precedent being set here is "CSS can't figure out how to fix this, so let's hack it in HTML instead".

That hits the nail on any <div> use case within <dl>.

Historically attributes (like microdata) where always a 2nd choice, if at all, to reinforce semantics, while tags where the first choice. And that's a good paradigm.

Historically since HTML 4+ CSS was meant to do the styling not HTML. The current state of the 95% web is horrible (inefficient non-semantic soup) precisely because things like flex-box and display: table took so long to agree upon and press forward and meanwhile people re-implemented their old table-layouts as div-class-soup (also called Bootstrap or Foundation).

Thus the whole paragraphes about itemprops and itemscopes makes me quite sad when I see how it is glued to a div when instead it could have been a semantic grouping element that made sense even IF the UA or user would not understand the microdata.

---

The other is related and has to do with semantically grouping elements. A single def-title can be described by multiple def-descriptions and/or multiple def-titles can be described by a single def-description. AFAIR currently the spec creates new dom nodes for every <dt> and attaches any followup <dd> to that <dt> instead of allowing a grouping element. That is and was a horrible design.

Sure headers and paragraphs also bundle up as semantic blocks that belong to each other by the spec. Still

and

and came around to give the authors more tools for explicit and semantic grouping on a very basic level - and I am still hoping for (as in data record).

A new <dg> instead of the pointless div-element would have allowed to group <dt> and <dd> that appear in any order. Else it would have worked like the current implicit grouping as far as I understood.

This whole issue here tries to fix this the semantic auto-glueing that is implied in def-lists. But instead of fixing it at the root, it simply patches in something that "works already" despite that it is bad design. Putting <div> inside <dl> where the only thing <dl> should be expecting as children are <dt> and <dd>, or in a better standard <dg>s (def-groups). A standard should primarily set a focus on what should be, not what is most lazy to implement. WHATWG did this very well for HTML 5 as did W3C for HTML 4; maybe the issue lies somewhere in the age of organizations? :(.

The Spec should:

• Prioritize tags over microdata for reinforcing metadata. Think of it like unobstrusive Javascript.
• Discourage self closing tags and attributes. It was and is just a horrible and pointless idea. Why not take the few good things of XHTML/XML and keep them.
• Define a semantic tag for grouping if <dt>s and <dd>s that can also be specified/targeted by CSS selectors as a nice-to-have side-effect

But obviously you are not going to change anything unless it fits the needs and desires of the current implementors of browser engines and/or their companies. I can see the practicability, doesn't mean that it is always the best long term thing to do.

[patrickdark]

@zcorpan: I think a new dgroup (or similar dg, di, dli, etc) element would be less confusing than re-use of the div element in consideration of @inoas' post at #1937 (comment).

I don't see why this requires parser changes either; just change the "Tag omission in text/html" text in the spec. See https://html.spec.whatwg.org/multipage/semantics.html#the-dt-element.

Right now, the aforementioned text for dt elements reads "A dt element's end tag can be omitted if the dt element is immediately followed by another dt element or a dd element." Append "and the element is not the child of a dgroup element" to the end of the sentence.

Do likewise for dd elements.

The only browser implementation change needed is a UA stylesheet update to make it a block-level element as was the case with the hgroup element, if I'm not mistaken.

[zcorpan]

Saying that the end tag 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.

If the end tag is optional sometimes and sometimes not, I don't think it would be less confusing overall. Some developers are likely to run into accidentally violating the rule and end up with a weird DOM and be confused.

[patrickdark]

@zcorpan:

Saying that the end tag 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.

I'd suggest that hypothetical tools that perform tag-stripping should not be considered relevant as these are (A) hypothetical and (B) have no bearing on the long-term use of HTML, which is more important.

If the end tag is optional sometimes and sometimes not, I don't think it would be less confusing overall.

In contexts where optional end tags are always used, this is a moot point.

I think tag omission should treated as a legacy issue rather than a feature that other features must yield to. In this case, a long-term feature is being created and it seems to be designed with the principle that tag omissibility is something that should be preserved.

Some developers are likely to run into accidentally violating the rule and end up with a weird DOM and be confused.

In an HTML spec amended as proposed, what you'd be describing is a syntax error. It's no different than an author ending up with an unexpected DOM because they forgot to terminate a span element within a paragraph element. If one doesn't write correct code, they don't get correct results.

[domenic]

I think tag omission should treated as a legacy issue rather than a feature that other features must yield to.

Tag omission is a crucial part of writing modern, clean HTML; several major style guides mandate it. It's one of HTML's greatest features in my opinion. Some may dislike it, but we certainly have no intention of treating it as a legacy issue.

[ianthedev]

Maybe a consensus is needed from the community on tag omission. While some may like it and think it makes HTML clean, I personally think it causes inconsistency among content-wrapping tags and makes HTML less careful. I myself always avoid using tag omission.

[zcorpan]

@patrickdark

I'd suggest that hypothetical tools ...

https://github.com/html5lib/html5lib-python

dl.html

<dl><dgroup><dt>hello</dt><dd>hello</dd></dgroup></dl>

test-serialize.py

import html5lib
f = open("dl.html")
tree = html5lib.parse(f)
str = html5lib.serialize(tree)
print str

$ python test-serialize.py 
<dl><dgroup><dt>hello<dd>hello</dgroup></dl>

[zcorpan]

@Ian-Y

Maybe a consensus is needed from the community on tag omission.

It seems pretty clear to me that there is no consensus on optional end tags in the community. As @domenic said, there are style guides that recommend it (e.g., this one), and just in this thread we see people with differing opinions. Some people like it, some people don't.

But consensus is not necessary to make a decision in the WHATWG. See the FAQ and an old post by Hixie.

[ianthedev]

@zcorpan Thanks. I see.

@patrickdark and all other who are interested in a new <dgroup> tag, I created a thread on WICG discussing about using <dt> and <dd> inside <ul> and <ol> instead. Here is the thread: Is the design of <dl> tag flawed?

[patrickdark]

@zcorpan

test-serialize.py

It's an improvement that we're not dealing in hypothetical tools.

I see no reason why the tool can't be fixed, however. It also seems that the tool is in a beta state—which suggests a good time for a fix—and two of its three libraries are dead, so I'm not sure how relevant it is.

Authors who have deployed this tool can use existing workarounds for lack of a description list grouping element until the tool is updated. (I'm not familiar with Python, but I'm guessing the fix would be relatively trivial too given that this tool seems to be based on an XML tree generator where tags are mandatory.)

@domenic

Tag omission is a crucial part of writing modern, clean HTML [...]. It's one of HTML's greatest features in my opinion. Some may dislike it, but we certainly have no intention of treating it as a legacy issue.

Tag omission is an optional—not crucial—part of HTML. I write code in XHTML where this shortcut is simply disallowed and haven't missed it.

Tag omission does allow one to write less verbose code, but this comes at the expense of code clarity. That we're even having this discussion about tag omission producing unpredictable DOMs using conventional source code structures seems to be proof of that.

(It also seems to be proof that the parsing design is fundamentally flawed and moreso if tag omission is a feature to be added to future elements, but since parsing changes are off the table...)

@domenic @zcorpan

there are style guides that recommend [tag omission]

You've pointed out a singular example that "recommends" tag omission after said style guide has declared that part of itself "optional". Further, it explicitly acknowledges that its optional recommendation is not part orthodox Web development instruction.

Further, this singular guide doesn't appear to be attributed to any individuals or organizations—despite its implied association with Google—and is written in a custom XML syntax instead of HTML, so I'm not sure why it should be held as a credible authority for determining the future evolution of HTML.

@zcorpan

But consensus is not necessary to make a decision in the WHATWG.

All the more reason to do the right thing and not shoehorn the div element.

But alas, I guess we're going to be stuck writing non-straight-forward dl > div and :not(dl) > div selectors forever just like we're already stuck writing annoyances like ruby > :not(rp):not(rt):not(ruby) because someone decided that the rb element is evil.

[chharvey]

I’d like to add my voice to the discussion, although I might not be adding anything new. I know others have already expressed similar views, and I also know other others will disagree. But I want to cast my vote.

I like the idea of repurposing/extending the <li> element to be allowed as children of <dl> elements, just as the <div> has been done currently.

“div is non-semantic” is not good enough

I understand the reasoning behind choosing div: there is no need to put in an extra ‘semantic’ element because the groups are already determined implicitly. However, I don’t think this is a very good argument.

First of all, the implicit grouping model goes out the window when we are now using an explicit element to group dts and dds together. In fact, I definitely agree that the content model of dl should be either 0 or more implicit groups or 1 or more ‹whatever› elements. Mixing these kinds of groups would be a nightmare. Using only ‹whatever› elements eliminates the need for the implicit grouping model, which is the whole reason for choosing div (as opposed to a more ‘semantic’ element) to do the wrapping.

Now, the first point is moot, because more importantly, there is indeed a reason for needing a wrapping element in the first place: to add semantics. I’m not talking about styling issues, which can & should be solved with CSS; I’m talking about markup issues, such as how to mark up dt-dd groups using Microdata and ARIA and other global attributes.

<h1>Important Dates:</h1>
<dl>
  <li itemscope="" itemtype="http://schema.org/Event">
    <dt><time datetime="2015-10-12" itemprop="startDate">Oct 12, 2015</time></dt>
    <dd itemprop="name">Topic Due</dd>
  </li>
  <li itemscope="" itemtype="http://schema.org/Event">
    <dt><time datetime="2015-11-12" itemprop="startDate">Nov 12, 2015</time></dt>
    <dd itemprop="name">Draft Due</dd>
  </li>
  <li itemscope="" itemtype="http://schema.org/Event">
    <dt><time datetime="2015-12-12" itemprop="startDate">Dec 12, 2015</time></dt>
    <dd itemprop="name">Final Paper Due</dd>
  </li>
</dl>

In this example, one could argue that ul or ol would be better suited for this list of dates, however we would then not be able to use dt and dd to mark up the date-description pairs, which poses the question, what elements should be used for those pairs? Since the items all have parallel structures, surely dt and dd are better than any alternatives. Inside a ul or ol, each li would be free-form, allowing any flow content, but in this example we have a stricter structure.

Side note: I know this isn’t really a convincing point, but I like to think of div as a ‘DIVision’ of a document, and I prefer to use it only as a last resort, when no other element will suffice.

introducing a new element is cumbersome

I agree with the many posts in this discussion about the costs of adding a new element, be it dg or di or something else. I think in this situation the li element is perfect. The spec says it “represents a list item,” which is more or less its purpose here in a dl list. In the current spec, the content model of div is dependent on its context (whether it is a child of dl or not), so I don’t see any reason why the same can’t be done for li.

If li were extended in this manner, I don’t think the rules for any element’s closing tag omission would need to change (although I prefer to always close all my tags anyway). The closing </li> tag may be omitted if followed by another <li> opening tag or by a </dl> closing tag (its parent); the closing </dt> tag may be omitted if followed by a <dt> or <dd> opening tag, and the closing </dd> tag may be omitted if followed by a <dt> or <dd> opening tag, or by an </li> closing tag (its parent).

Incidentally, how fitting would it be for an li to be an acceptable child of all three lists, ol, ul, and dl?

[zcorpan]

Mixing these kinds of groups would be a nightmare.

Mixing is invalid.

how to mark up dt-dd groups using Microdata and ARIA and other global attributes.

You can do this with div.

I think in this situation the li element is perfect.

li has the most problems, see #1937 (comment)

[chharvey]

1. rightfully so, which is why I said I agreed with that part of the content model.
2. :tongue-in-cheek response: you can also do it with section, but you don’t see that written in the spec! … More seriously though, my point was that we needed a reason for a wrapping tag in the first place, which is to add semantics—Microdata, ARIA, the grouping of dt-dd sets, etc. Since we need to add semantics anyway it doesn’t make sense to use a "non-semantic" element. So really, anything is better than div, and li is the best choice.
3. Regarding the problems with li:

• The </li> end tags can still be omitted as long as the li is followed by another li element or reaches the end of the parent dl element. This is exactly the same requirement for li children of ol and ul elements.
• The default styling shouldn’t be an issue. Browser default stylesheets can (and should) be updated when the spec is updated, but even if not, author CSS can fix the styling. This feature would also be backwards-compatible, i.e. allowing dl > li in the spec won’t break current CSS.
• I can’t speak to AT and I’m not sure what you mean by “changed,” so I’ll leave that one alone.
• The numbering issue seems like a bug. The li items of a dl shouldn’t be numbered or bulleted (or should they??), but this goes back to the second point above: the default styling of dl should have list-style: none, and this can be fixed.

I understand your reasons for not wanting li, but I think the benefits in the long run will outweigh the costs in the short run. This community has a real opportunity here to make lasting change for the better. If done properly, tools like browsers, parsers, and assistive technology will conform. In fact, they should conform to stay ahead in the game of evolution. Tools that don't constantly update and conform to specifications will fall behind and be overtaken by better, smarter tools. Just look what happened to IE.

I think it comes across as near-sighted to make a decision based on the way things currently are and how today’s tools work at this time, in fear that a change will cause one of them to break. I get the whole pave the cowpaths concept but allowing dl > div just seems like a hack, and encouraging authors to do it is subjectively wrong.

[zcorpan]

If you get all implementations to change such that the problems with li are gone, I'm happy to change the spec. But the spec doesn't have any power to make everyone conform just because we wish so. There has to be interest from implementors to change or we're just wasting time and the spec will be a work of fiction.

#1937 (comment) demonstrates what the parsing problem is.

[inoas]

Now this is just logical but still bad: #2007 (comment) - why would divs work here but not there? I can see the point. But the solution is to not have a div tag but be patient with browser vendors to implement a or tag. There is no need to hurry on this one and it can easily take 3 years and almost no harm will be done because the addition of dt/dd grouping is really a minor feature (compared to such things as http2, webasm, fetch or push/preload etc.)