W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13128] Allow wrapping list items in DIV elements

From: <bugzilla@jessica.w3.org>
Date: Wed, 24 Aug 2011 21:25:29 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QwKwz-0006gg-Is@jessica.w3.org>

Marat Tanalin <mtanalin@yandex.ru> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #15 from Marat Tanalin <mtanalin@yandex.ru> 2011-08-24 21:25:26 UTC ---
(In reply to comment #13)

> This isn't really supported by browsers currently. For example, IIRC legacy IE
> will ignore </li> so the <div> in the example in comment 8 will end up inside
> the <li> even if you include the end tags.

Such old IE versions (6+7) has very little market share--less than 10%. So they
cannot be a reason to abandon improvements in the HTML standard at all.
Backward compatibility is a good thing, but it has its own limits---main limit
is common sense.

> There are several reasons that this is non-conforming in HTML, the main one
> being it is massively error-prone.
> I disagree with the premise that omitting end tags is bad form. We certainly
> should not be ignoring issues relating to omittable end tags on the basis that
> authors who fall prey to such problems deserve it for not being proper authors.

"Several lists" is not same thing as "one list that consists of same items".

If a web-developer wants to use one sematic list with items wrapped in divs
instead of using several separate semantic lists, then he cares about

If a web-developer do care about semantics, then he always use closing tags.

If web-developer do not care about semantics, then he likely does not
distinguish "one semantic list / several semantically-transparent DIVs inside"
from "several different lists", and so has no reasons to use divs inside lists
at all as well as does not care about things such as standards and validation.
Such web-developers are not limited to spec at all and can easily use invalid
markup right now, so it's not of HTML-spec responsibility to consider such
cases as a stoppers.

The purpose of making DIVs inside lists formally allowed is to make possible to
not divide one semantic list to several ones just for styling purposes while
keeping code formally valid. One single semantic list should be marked up
exactly as one single semantic list. For styling purposes, DIV's should be
used---regardless of a context where they are needed and used---be it for
grouping paragraphs, or list items, or any other text containers.

AFAIK, requirement that list items should be direct children of list has been
introduced into spec _long before_ common containers (DIV and SPAN) have been
invented. So, current limitation is nothing more than just rudiment that has
been _accidentally_ kept in HTML spec when DIV/SPAN elements has been invented.

To make using divs inside lists clear, we can just clearly describe requirement
in HTML spec like this:

DIV element as direct child of list is allowed only if all items of the list
has closing tags. Otherwise, markup will be ambiguous and should be considered

That's all.

> (In reply to comment #10)
> > 
> > It's not purely a styling issue, it's a logical issue.  There's no way to
> > indicate that several consecutive li's are logically related, for style or
> > script or any other purpose.
> What's the use case here? I don't completely follow. Why doesn't the class=""
> attribute handle this adequately?

Consider this example where list is multi-column (each div is separate column):

UL {display: table; }
UL > DIV {display: table-cell; }


How do you achieve same effect with classes assigned to single list items?

(Just in case: please do not mention CSS3 Multi-column Layout---such means are
very limited in practice.)


Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 24 August 2011 21:25:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:17 UTC