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 https://github.com/w3c/csswg-drafts/issues/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 :+1: 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 https://github.com/whatwg/html/issues/1937#issuecomment-255339408 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 https://github.com/whatwg/html/pull/1945 Test cases for conformance checkers at https://github.com/w3c/web-platform-tests/pull/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 https://github.com/whatwg/html/pull/1945/commits/280785401785239f059061eed79f073662bcc49e

[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]

It cannot wrap tr because non-table tags in tables get inserted before the table (called "foster parenting" in the spec). There is also a wrapper element for tr already (tbody).

We don't allow anything anywhere in order to help catch authoring mistakes. This issue is about dl; if there is a specific problem to be solved for some other element, please file a new issue. Thanks!

[zcorpan]

Well if it is backwards compatible anyway I personally don't see a reason not to allow <div> for grouping.

Great!

However I still think that at the same time it should be decided to add li or dg or di support.

I think they should not be added.

[Crissov]

I’ve felt the need to group <li>s before without having to introduce nested lists (like @TiddoLangerak mentions), so I would not be against adding <div> as a wrapping element in all types of HTML lists, but maybe it’s indeed simpler to track that in a separate issue.

[inoas]

I think @TiddoLangerak makes a good point. As a non-semantic element for technical-grouping, div should be allowed everywhere.

However @zcorpan would you explain why you think li or di or dg are bad?

[zcorpan]

I have explained that in https://github.com/whatwg/html/issues/1937#issuecomment-255080560 and https://github.com/whatwg/html/issues/1937#issuecomment-255346536

[zcorpan]

Replying to part of an earlier comment

It will just take time for vendors and users to update their software.

This is not correct. It doesn't just take time. It also takes convincing of every vendor that they should change their HTML parsers to solve this problem. Browser vendors are very much against making any change at all to the HTML parser, as it happens; see for example https://github.com/html5lib/html5lib-tests/issues/78 (a spec change from 2013 that has still not been implemented in WebKit, Blink, or Edge). So if you want a new element that requires parser changes, you first need to convince the browser vendors.

[inoas]

@ your explanation

• If you don't close tags, then that's what you get out of it, IMHO (short: I don't support that html5 has no-value attributes and auto-self closing tags, it only leads to a lot of issues and has little to no benefits for authors and I hope it will disappear with maybe "html6"; it was one of the things that xhtml did right)
• For future use a semantic grouping would greatly improve the usability of def-lists.
• From an authors point of view, I don't see a problem having optional <li>s (or <dg>s or <di>s or <dli>s).

What is so bad about point 2 @ https://github.com/whatwg/html/issues/1937#issuecomment-255340374

I did already say that if div implementation is pragmatic to do, I'd like to see it happen. All I say is that while that's good, a semantic grouping element for def-lists makes sense, at least to me.

[zcorpan]

If you don't close tags, then that's what you get out of it, IMHO (short: I don't support that html5 has no-value attributes and auto-self closing tags, it only leads to a lot of issues and has little to no benefits for authors and I hope it will disappear with maybe "html6"; it was one of the things that xhtml did right)

It does not really matter what your opinion is about optional end tags; the parsing problem is still there.

For future use a semantic grouping would greatly improve the usability of def-lists.

Usability for whom, for what? The original problem statement said nothing about improved usability.

From an authors point of view, I don't see a problem having optional <li>s (or <dg>s or <di>s or <dli>s).

If we ignore the problems of those, I still think it is bad language design to allow multiple elements to do the same thing. It also ends up with endless discussions about which element is "better" or "more semantic" (q.v. abbr vs. acronym).

What is so bad about point 2

It has these problems:

• parsing when end tags are omitted.
• default styling is wrong; the bullet should not be there.
• user experience in assistive technology is changed.
• If <dl><li> is put inside an <ol><li>, the dl's li gets a number that continues the ol's numbering, which is clearly wrong. See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4607

I did already say that if div implementation is pragmatic to do, I'd like to see it happen. All I say is that while that's good, a semantic grouping element for def-lists makes sense, at least to me to me.

Noted.

[inoas]

Usability for authors that want to semantically group. Usability for disabled that are benefitting from grouping.

As for the concerns.

• The default styling of <li> inside <dl> for UAs that don't yet support it would only matter for new content being created. Such content could set list-style property for backwards compatibility
• I don't see that <li> would be mandatory so the stripping is only a smaller problem. Also 3rd party tools (e.g. not browsers) can be updated.
• user experience in assistive technology is not only changed but it is improved "in future". As long as vendors would not implement the tag - there is time to catch up.
• the ol dl li thing is really bad

[zcorpan]

Usability for authors that want to semantically group.

I don't understand why div is worse for authors compared to the other options.

Usability for disabled that are benefitting from grouping.

Exposing groups in dl to end users is possible regardless of whether there is a wrapper element. That's why the wrapper element itself has no additional semantics. I am not aware of a screen reader that actually exposes groups in dl in any way, though.

[zcorpan]

@fantasai do you still think div is a bad idea, or do you think it's OK?

At this point I think these are the possible choices:

1. Go ahead with the div proposal and be done with it.
2. Drop the div proposal and don't solve this problem at all.
3. Drop the div proposal. Come up with a new proposal including changes to the HTML parser, and try to convince browser vendors to change their HTML parsers for a new element. When 2+ browsers have shipped the change, we can allow authors to use the new element in HTML.

I am not going to work on (3) personally, though.

[Crissov]

• dl: description/definition/data list
• dt: — topic/term
• dd: — definition/description/data
• div: — item vector/value/vault/vvrapper… 😉

[tabatkins]

vvrapper

You're going to jail.

[fantasai]

@zcorpan I do think it'll cause fair amount of confusion, especially since there is no parallel use of <div> in other list types. The other cases you cited are much more specialized, so it's less surprising that there are special rules for their content model. But, you don't have to take my word for it--ask some people who teach HTML what they think.

The flip side is, of course, that during the (5yr+) transition period, a new element would require not only closing tags for itself, but also the preceding </dd>. So I'm not sure which is worse in terms of confusion. (On a related note, it is kindof annoying that unknown tags aren't handled sanely in omitted-tag contexts... wonder if that's fixable, generally, for future us?)

I've used <li> as a wrapper before out of obstinateness, and in my case it worked, but the <li> in <dl> in <ol> thing sure is weird and imho rules that out. :/

Again wrt implementation concerns: misnested-tag bugs in HTML parsers is definitely tricky, but is adding a new element really quite as difficult? It shouldn't be. Especially if it has the same parsing rules as, say, <div>. Might be worth asking around.

See also glazou's concerns wrt editors.

[zcorpan]

It's not difficult, but I'm very skeptical that browsers are interested in making changes to the HTML parser for this issue. As far as I can tell there is very mild interest in making any change at all to the HTML parser.

[zcorpan]

But, you don't have to take my word for it--ask some people who teach HTML what they think.

cc @itpastorn

[itpastorn]

How hard would it be to teach the various proposals? My experience makes the following points reasonable:

1. Caveat: When teaching students they rarely come up with a situation that requires grouping within dl-lists at all.
2. Grouping with HTMl would be prefarable to CSS. There seem to be at least the semantic value "these belong together".
3. <di> is way to close to <div> for the eye. It will be confusing.
4. There is quite a lot of material on the web and elsewhere explaining <li> Adding a new function for that tag will be confusing.
5. <dg> would be the easiest to teach, but special rules for <div> are ok. I do not think the model where <dl> could contain either <dt> and <dd> or <div> that in turn can only contain <dt> and <dd> is very hard to explain.
6. I always teach my students to explicitly close all tags, until they know what they are doing really well. I can not speak for all educators, but requiring closing tags is not a problem either.

[fantasai]

@zcorpan Thinking about this some more, I think the biggest problem I see with choosing the <div> solution here is you've established that "Parsing new tags is hard, let's just use <div> whenever we need a new one" as a design principle of future HTML. Because you haven't established that <div> is a better or more natural solution to the problem than a new tag; you've only established that it is easier implementation-wise, which is of course true in any case that could potentially require a new tag.

[cscott]

@fantasai I don't think that's the precedent here -- plenty of new tags have been added recently, in fact. It's just the strange autoclosing parsing rules for list tags which are causing problems here. The precedent is more narrow: "Parsing new tags inside list context is hard...". I think everyone agrees that the special rules for list-related tags were unfortunate and that design won't be repeated in the future.

[Hixie]

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

[fantasai]

@Hixie That's not the issue, actually. If I thought this solution belonged in CSS I'd put it on our radar, even if far out in the future. But I don't think this is a CSS problem; I think it's a markup problem for the reasons mentioned previously: that the definition group should be easy to target with fragment identifiers, that it should be possibly to manipulate as a single element in JS as well as CSS, and that it should be easy to assign attributes like lang, dir, class, etc. to the definition group. The fact that the group is well defined without the grouping element doesn't solve all the requirements of having an element representing said group, just the grouping aspect of it.

[tabatkins]

@fantasai Recall the additional point zcorpan (I think) made above - the grouping element isn't adding any new semantics at all in this situation. The semantics of a dt/dd group are already present in the markup; adding the wrapper element merely adds a meaningless container element to help you with various practical issues, such as the ones you list. Given that, div is pretty appropriate for this situation, as it's already the standard element for adding non-semantic block-level grouping.

[therealglazou]

• first, I think this should NOT have been merged in issue #1945 without some metrics on impacted Wysiwyg editors... It can sound harmless, but it's actually a rather big change in one of the very painful areas of Wysiwyg editing, list handling. It's not only about being able to insert correctly the relevant element somewhere, it's also about converting one list type to another one, as Wysiwyg editors do... It's also about copy/paste behaviour, that will imply looking at the children of all pasted topmost elements in the clipboard, and enclosing DL detection. All in all, it DID deserve metrics and a more careful understanding of what it will change/break in content editors. And I don't forget it requires a change about DIV styling in the default html stylesheet, which seems to me a bad choice. About the fact a semanticless DIV should be allowed anywhere: I disagree, and the table model does not and will not allow this, IMHO; I also hate the fact DIV is called "generic" but should, being a child of DL, contain only DTs and DDs... Ahem.
• in my opinion, a valid possibility has always been forgotten in the ways of solving this issue: the model of DT could be changed to allow DD elements at the end of its children... I'm not saying it's THE solution, I'm only saying it's a solution was not considered and discussed (in this issue). Please note that the issue is the second topmost issue in lists after the painful model of UL/OL. Both issues are well known since the first day of DL and UL/OL.

So I collected data about all the Wysiwyg editors (only actively maintained ones) I have here on both OS X and Windows, both online and standalone. The results are visible at http://disruptive-innovations.com/zoo/csswg/editors-DT-in-DIV.html

Only three editors, core or app, are impacted and they represent only two core editors. Please note they're not minor editors, though... All the others don't really deal with DL/DT/DD and inherit their behaviour from the underlying core editor in the rendering engine.

Other metrics should be collected: DL/DT/DD global usage, ratio of valid DLs vs. invalid.

All in all, I think it's worth discussing this with at least Adobe and Mozilla to know if they can update their code, their DL/DT/DD behaviour and when. I also think the copy/paste behaviour should be discussed, because it's actually far from simple. What happens if the user tries to paste a DIV containing a DT and a P inside a DL (let's say the caret is at beginning of a leading DT inside the DL)? Where goes the P?

[zcorpan]

Thank you for testing @therealglazou!

In the results, column 3 says

Expected markup is <dl><div><dt>foo</dt><dd>bar][</dd></div><div><dt>][</dt></div></dl> or <dl><div><dt>foo</dt><dd>bar][</dd></div><dt>][</dt></dl>

Mixing div and dt children in dl is not allowed.

I have filed https://github.com/w3c/editing/issues/153 to discuss changes for contenteditable.

first, I think this should NOT have been merged in issue #1945 without some metrics on impacted Wysiwyg editors...

OK. I filed https://github.com/whatwg/html/issues/2005 so we can improve our process.

And I don't forget it requires a change about DIV styling in the default html stylesheet, which seems to me a bad choice.

I think it does not need any change. Can you elaborate?

in my opinion, a valid possibility has always been forgotten in the ways of solving this issue: the model of DT could be changed to allow DD elements at the end of its children... I'm not saying it's THE solution, I'm only saying it's a solution was not considered and discussed (in this issue).

This would require parsing changes as well (a dd start tag closes the dt element). I doubt it would be Web-compatible.

Other metrics should be collected: DL/DT/DD global usage, ratio of valid DLs vs. invalid.

What do you think we should do with this data?

All in all, I think it's worth discussing this with at least Adobe and Mozilla to know if they can update their code, their DL/DT/DD behaviour and when. I also think the copy/paste behaviour should be discussed, because it's actually far from simple.

That sounds good; I suggest someone who is interested in discussing these file issues at the relevant venues (I can do that if nobody beats me to it). Please link to such issues in this thread so we can follow up.

[inoas]

@itpastorn agreed on <di> but what's wrong with <dg> - why not pick that over <div>? Also I'd rather see auto-closing of tags being a quirksmode on browsers than actually a support by standard. It is a very bad feature - probably the most single bad thing that HTML5 reintroduced (aside that <3).

@fantasai no @Hixie is right, that is exactly the issue here. Having no grouping element is the issue for all the problems here. Slapping on <div> just because you can is the lazy way out. Browsers can do that if they think its nice for authors. A standard should not define bad design.

Rant: Sorry guys but this is going into the wrong direction. I will say it from the outside, as I am just a regular long-term web-author:

It is a lazy solution. Grouping does make sense semantically. Currently the group is IMPLIED, a <dt> followed by a <dd> is the semantic group. By skipping to have a semantic tag for this semantic group we got into trouble of making it harder to style through CSS - or even apply microtagging - than it would need to be.

Now why not apply a hack and simply use <div>-soup where-ever its opportune, right? Wrong message to (new) authors (and stand-alone-editing software failing should raise a red flag to you). The current trend is a tables-2.0-through-div-soup anyway. Wrong message to future where the web could become more sleek, clean and semantic.

I am out. Enjoy the mess.