Allow <div> around each <dt><dd> group in <dl>

[zcorpan]

This only changes the content model and the rules for determining
what a dl element represents.

Fixes #1937.

[domenic]

Does div need its "contexts in which this element can be used" updated?

[zcorpan]

Done.

[domenic]

Should we update the short paragraph describing the div element, and the note describing it as an element of last resort?

[zcorpan]

I updated the description, but not the note. I don't want to tweak div itself so much in this PR, that seems like a separate issue.

[domenic]

I guess we should also put updating the FAQ as an action item after this is merged :)

[zcorpan]

I'm thinking of replacing these paragraphs with an algorithm for how to get the groups of a dl element, since right now they are probably a bit confusing and not so helpful if someone wants to actually get the groups of a dl element (in an HTML scraping tool for example).

My thinking is that the algorithm should be something like this:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4601

[zcorpan]

Use the priceCurrency property (with ISO 4217 codes e.g. "USD") instead of including ambiguous symbols such as '$' in the value.

http://schema.org/price

[gunnarbittersmann]

Why would you want to allow div as child element of dl?
XHTML 2 had proposed a di element for that purpose: https://www.w3.org/TR/xhtml2/mod-list.html#edef_list_di. An earlier draft of HTML5 had included di as well. It has been removed later because Hixie had no use for it.
Why not introduce di now?
The problem I see with div: for not allowing any content, but just dt and dd children, another complicated if-then-else rule for its content model is needed. It would be easier with di: dl may have di, dt and dd children; di may have dt and dd children; div can stay as it was.

[annevk]

@gunnarbittersmann I suggest you read through #1937. Lots of alternatives were considered.

[Marat-Tanalin]

According to the HTML5.org’s Nu Html Checker, looks like we still cannot use multiple nested DIV elements around DT/DD:

<dl>
    <div><div>
        <dt>Lorem</dt>
        <dd>Ipsum</dd>
    </div></div>
</dl>

If this is intentional (hopefully not), this is a huge limitation that makes the feature much less useful.

[zcorpan]

It's intentional, see #1937 (comment)

[Marat-Tanalin]

@zcorpan Thanks, Simon. That’s a real shame. I was intending to adopt the feature, but now I’m forced to switch back to the previously used UL→LI→DL approach since styling often needs more than one nested element, and obviously the only purpose of allowing DIV inside DL was styling while DIV itself has no semantics.

Could you explain why exactly in practice (besides just an intent to make the content model as strict and simple as possible) using more than one DIV wrapper for DT/DD would be undesirable or impossible?

I believe there is nothing that makes this:

<dl>
    <div><div>
        <dt>Lorem</dt>
        <dd>Ipsum</dd>
    </div></div>
</dl>

less possible than this:

<dl>
    <div>
        <dt>Lorem</dt>
        <dd>Ipsum</dd>
    </div>
</dl>

(Please let me know if it’s more appropriate to discussing this in the thread you’ve referred to).

[zcorpan]

I was not aware of use cases that required multiple nested elements (I don't recall it being stated as a requirement in #1937), and so went with the strict and simple approach. Why do you need multiple elements? Can you point to something where you currently use ul?

Allowing arbitrary nested divs makes several things more complicated: conformance checkers, learning the language, data mining tools that get the name-value groups (the spec has an algorithm for it), as well as WYSIWYG editors wanting to support this structure.

[Marat-Tanalin]

Why do you need multiple elements? Can you point to something where you currently use ul?

DIV is by nature a generic container free of semantics and intended solely for styling and scripting. Allowing DIV inside DL is obviously a way to overcome current shortcomings of CSS. Styling often involves using multiple nested elements to achieve the required result.

I use DL a lot, e. g. for lists of blog-post comments. Recently, I’ve implemented (not rolled-out yet) sending comments via Ajax in my blog, and planned to show each newly added comment with an animation of height smoothly increasing from zero to the actual height of the comment block including its padding. But for this to be possible, the animated block itself should not have a padding while the (only allowed) DIV in my case does have a padding (which is natural: as long as I’m now able to use DIV wrappers for DT/DD, it’s no longer reasonable to use the painful and limited workaround of applying partial styling to DT and DD instead of styling the wrapper itself). Then I’ve added another DIV specifically for the height animation, and… have discovered that’s invalid. o_O

Allowing arbitrary nested divs makes several things more complicated:
conformance checkers,

Complicating conformance checkers is probably a minor thing. And actually, complication is obviously quite little.

learning the language,

Quite the contrary, it was always possible to nest multiple DIV elements, so being unable to do this in a certain context (DL) is unexpected and confusing. Moreover, many developers will almost certainly blindly use multiple nested DIV elements inside DL with no doubt as they used to.

data mining tools that get the name-value groups (the spec has an algorithm for it), as well as WYSIWYG editors wanting to support this structure.

Given that DIV is the only allowed wrapper element between DL and DT/DD, it’s trivial and straightforward to find DT/DD by DL and vice versa regardless of how many nested wrappers are used (e. g. in JS, DL for a specific DT can be found with dt.closest('dl')).