(In reply to comment #0)
> * list semantics are unnecessarily complicated for authors in that minor
> differences in type warrant completely different list elements which mostly
> exist due to a presentational heritage

That's a very subjective statement and seems to be completely unsupported by any evidence.  I would argue that the concept of ordered and unordered lists are not presentational in nature, and from an authoring perspective, providing separate elements for numbered and bulleted lists is very easy, and has worked well for years.

>  * authors cannot mix definition list items with non definition list items a
> the same hierarchical level 

Please explain what use case you are trying to address.

>  * lists are inherently ordered and in static HTML necessarily so (why three
> separate list structures then)

Because the difference between them is whether or not the order is significant to the meaning of the list.  Consider the difference between, for example, a list of ingredients needed to bake a cake, and a list of the steps needed to make it.  The order of the former is irrelevant. As long as all ingredients are available, the cake can be made. But for the latter, the order is relevant for many of the steps.

> (see http://esw.w3.org/topic/HTML/ListContentModelImprovements for evolving
> solution proposals)

I note that there is no related email discussion on the mailing list for this issue.  Please avoid raising issues in here which have not even had any discussion on the mailing list.  I don't think it's appropriate to simply copy and paste all the issues recorded in the wiki to here, since we want to make this useful, not let it be flooded with noise like the wiki was.

(In reply to comment #1)

>>  * authors cannot mix definition list items with non definition list items a
>> the same hierarchical level 

> Please explain what use case you are trying to address.

Primarily this is meant to address the bullet you didn't reply to and provide greater flexibility for authors. Some have proposed including a DI (definition item) to solve this problem, but there is not reason we cannot simply use the existing LI element to provide sufficient semantics for definition lists. Likewise there is no reason a user or UA cannot fully comprehend the semantics conveyed by <ol><li><dt>...</dt><dd>...</dd></li></ol> and meet the needs of authors. Similarly, this provides authors with even more flexibility if we broaden the content models accordingly.

Please keep to one issue with bug, that will allow individual issues to be more easily tracked and will prevent things from falling through the cracks.

As to these problems though, I think they're not really big issues. List semantics in HTML are really simple compared to almost any other list structure markup I've seen, and authors clearly have few problems using them -- lists are among the most-used elements in HTML. Indeed, even tables, which are far more complicated, get used a lot, so I think optimising these features for ease of use would be optimising in the wrong place.

The amount of structure provided by the three main kinds of lists (ol/ul/dl) is quite satisfactory for most needs; like with anything, they don't provide all the different options but they are good enough for most purposes, which is what we want. We could add things like mixing <li>s and <dt>s but in practice the parsing aspects preclude this being done usefully, and frankly I think this would complicate things, and, as you noted earlier, we don't want things more complicated for no good reason.

Regarding why we have three list structures, it's mostly historical. At this point the cost of changing it would outweigh the benefits, especially since we'd have to keep the three existing structures anyway.

The suggested solution isn't to get rid of the three list structures, it is to allow the content model of the LI to be either FLOW or DT followed by DD. This additional structure is a request made frequently by authors, and I see no reason why we shouldn't allow it. It requires no additional implementation by most UAs that I'm aware of, but it meets and author articulated need.

That would significantly complicate the language, not make it simpler. Authors are already confused enough with the behaviour of implied end tags without mixing the <dt>/<dd> and <li> magic into the same content model.

(In reply to comment #5)
How does providing the flexibility to structure DT and DD into list items complicate the language?

The more you allow, the more complex the language becomes. We have to define the semantics of everything, authors become more likely to make mistakes, validators are less able to call out certain problems, etc. Since it isn't clear that the HTML4 list structures are causing any problems, changing them seems unwise.

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.

No longer waiting for a reply on this bug.