Html: Allow <div> to group <li> inside <ol>/<ul>…

[Crissov]

Depending on the final solution to #1937, it will probably make sense – albeit less than inside dl – to have div elements be able to group list items in all other kinds of lists, especially li inside ul and ol.

Possible use cases

Pros and cons without labeling each li:

<ul>
  <li class="pro"> A supporting argument
  <li class="pro"> Another supporting argument
  <li class="con"> An opposing argument
  <li class="con"> Another opposing argument
</ul>

<ul>
  <div class="pro">
    <li> A supporting argument
    <li> Another supporting argument
  </div><div class="con">
    <li> An opposing argument
    <li> Another opposing argument
  </div>
</ul>

I guess it could be helpful when partially/successively revealing lists, e.g. in onscreen presentations. If I remember correctly Lateχ Beamer supports specialized commands (or environments?) for that, but also its angle bracket syntax for \item.

This HTML may be generated from either of the following Markdown codes (although Commonmark says otherwise):

+ A supporting argument
+ Another supporting argument
- An opposing argument
- Another opposing argument

```markdown

Pros and cons

• A supporting argument

• Another supporting argument

• An opposing argument

• Another opposing argument

The latter would result in a single list with paragraphs `p` within (at least the middle) list items `li`, the former would be two separate bullet lists – at least according to Commonmark.

Plain-text software changelogs often have different bullet types for types of updates, e.g. ‘bug fix’ and ‘new feature’.

### Recipes with multiple components

```html
<ul>
  <li class="pasta"> 500 g spaghetti
  <li class="pasta"> 2 l water, boiling
  <li class="pasta"> pinch of salt
  <li class="sauce"> 500 g tomatoes, minced
  <li class="sauce"> 100 ml olive oil
  <li class="sauce"> Grandma’s herbs
</ul>

<ul>
  <div class="pasta">
    <li> 500 g spaghetti
    <li> 2 l water, boiling
    <li> pinch of salt
  </div><div class="sauce">
    <li> 500 g tomatoes, minced
    <li> 100 ml olive oil
    <li> Grandma’s herbs
  </div>
</ul>

[zcorpan]

For this to be equivalent to the dl change, you would only be allowed to have a div wrapping each individual list item. Which is pointless, and you could as well have the div inside li.

If you want to group several list items together, that seems like a separate use case from that of dl, and I don't see why it wouldn't apply to dl equally.

In your examples, it seems to me it's actually two lists, so should be two ul elements.

[Crissov]

Maybe. div’s content model inside dl could still be changed from dt+ dd+ to (dt+ dd+)+, but then it wouldn’t exactly match the implicit grouping anymore. I’m not sure that’s a bad thing.

The equivalent to <dt> Foo <dd> Bar in Lateχ is \item[Foo] Bar, whereas <li> Baz would be \item Baz. That shows it’s a matter of philosophy whether li is equivalent to dd or dt dd.

[chharvey]

I agree with @zcorpan . if there is any reason to semantically group list items together, you may as well have separate lists.

[TiddoLangerak]

The div wrapping of dt/dd wasn't for semantic reasons either, but just for practical purposes. As the OP of #1937 already stated (emphasis mine):

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.

I think a similar argument can be made for li. For example, grouping lis can make it significantly easier to display a list in multiple columns without having to split it up in several individual lists (css columns don't always cut it, since AFAIK they don't allow you to target individual columns).

[zcorpan]

If there is a problem with CSS multicolumn, I suggest you bring it up with the CSSWG. CSS multicolumn is implemented and maintained, so no need for HTML to work around problems with it.

The OP lists "possible" use cases; I suggest these are not particularly common requests and we should not change HTML to address them. Any change to HTML has a cost and in this case I don't really see much benefit.

[Crissov]

I only brought it up because it was mentioned in the <div><dt><dd></div> discussion that it may make a better mental model etc.

[inoas]

Introducing div as a semantic groupening element without being semantic to dt/dd was an error already, but at least there was a use case that wasn't sufficiently fulfilled (think like if or where missing from the table tags) - this here, as explained can easily and logically be done by sub groups. No need to create more mess; deriving the mental model actually shows that dt/dd should have been done the non-lazy-way by adding a dgroup tag.