This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Common fundamental issue with parent/child relations in HTML spec as a whole is described in bug 13062. Current one is, in particular, about wrapping _list items_ in DIV elements. Nothing brand new here, this already works right now in all current browsers and just needs to be made formally valid by documenting it into HTML spec. Such documenting is one of fundamental purposes of HTML5 itself. Following applies to lists of all types -- UL, OL, DL. DIV is a common container element, completely free from a semantic sense. So, it should be allowed to wrap list items in DIV elements (any number of). Spec requirement that LI elements should be direct children of UL element should be removed and replaced with such as following (same applies to DT/DD as children of DL): "List element should be first _structural_ parent of item element" (with any number of wrapping DIVs between list and its items in hierarchy). For example, following code should be considered valid: <dl> <div><div> <dt>Lorem</dt> <dd>Ipsum</dd> <dt>Dolor</dt> <dd>Sit</dd> </div></div> </dl> <ul> <div><div> <li>Lorem</li> <li>Ipsum</li> </div></div> </ul> Current browsers' behavior is already OK (see testcase URL): elements are styleable; DOM tree exactly corresponds to source code and is not modified by browser's parse error corrections. Tested in: Firefox 3.0-5.0; Chrome 9.0-12.0; Opera 10.0-11.5; IE 7-9. Appropriate HTML spec parts just in case: http://www.w3.org/TR/html5/grouping-content.html#the-ul-element http://www.w3.org/TR/html5/grouping-content.html#the-ol-element http://www.w3.org/TR/html5/grouping-content.html#the-li-element http://www.w3.org/TR/html5/grouping-content.html#the-dl-element http://www.w3.org/TR/html5/grouping-content.html#the-dt-element http://www.w3.org/TR/html5/grouping-content.html#the-dd-element Thanks.
I agree that this would be useful as a styling hook and such. Do you have a specific case where you want to do this, though? I can't immediately think of a case where you'd want to style a group of list items differently. Specific use-cases hold much more weight than arguments from principle (although I do agree with you here).
I guess you could argue no use-case is needed here, though. The only purpose for making markup like this invalid is if it makes no sense or suggests the author made a mistake, and none of those is true. The philosophy with authoring conformance is usually that we leave things valid unless we have a specific reason to make them invalid. I don't see any reason to do that here.
For <ul> and <ol>, there is no need for this. Anything you can do by wrapping <li> in <div>, you can instead accomplish by moving the <div> inside the <li> and adjusting your styles appropriately. Same with the <dl>/<div> issue in your example. The one place that still has a problem is in styling a single <dl> "item" - that is, a single set of <dt>s/<dd>s. This has been discussed many times in the past, and it's still probably something that should be solved at the CSS side, as the necessary relationships are already present in the HTML.
(In reply to comment #3) > For <ul> and <ol>, there is no need for this. Anything you can do by wrapping > <li> in <div>, you can instead accomplish by moving the <div> inside the <li> > and adjusting your styles appropriately. You could, but only by adding more markup. Consider something like ---- <p>To-do list, in descending order of priority: <ol> <div class=urgent> <li>Put out fire in my apartment. <li>Foil plot to murder the president. </div> <div class=important> <li>Destroy invading aliens before they reach the Earth. <li>Devise cure for cancer. </div> <div class=unimportant> <li>Rescue kitten from tree. <li>Go to work. </div> </ol> ---- Yes, of course you *could* just put the classes directly on the <li>s, but why should you have to? This is exactly what divs are for. The only reasons I can think of to disallow this are 1) If you mix li's that are children of divs with ones that aren't, you have to be careful to explicitly close any <li> that precedes a <div>, or else it will be parsed wrong. (This applies to bug 12609 too.) 2) It makes programmatic list handling more complicated, because li's might legitimately not be children of their containing list anymore. But neither of these problems seems very strong.
(In reply to comment #3) > For <ul> and <ol>, there is no need for this. Need or not, this _does_ work in real browsers and should be just documented into spec to make it formally (that's all) valid. > Anything you can do by wrapping > <li> in <div>, you can instead accomplish by moving the <div> inside the <li> No. The bug is _not_ about wrapping _single_ LI in DIV at all (that would be of course pointless). Code examples in bug description are more than clear. > The one place that still has a problem is in styling a single <dl> "item" - > that is, a single set of <dt>s/<dd>s. This has been discussed many times in > the past, and it's still probably something that should be solved at the CSS > side, as the necessary relationships are already present in the HTML. This has nothing to do with the current bug.
It turns out another reason I want this is for execCommand(). Suppose you have markup like <ol> <li>foo <ol style=color:red> <li>bar <li>baz </ol> </ol> and the user selects the inner list and runs execCommand("outdent"). This should get rid of the inner list and make its two items items of the outer <ol>, but should also preserve the style. If the spec allowed it, I would make it do <ol> <li>foo <div style=color:red> <li>bar <li>baz </div> </ol> Reapplying the style to the children will work in execCommand()-specific cases, but it won't work for arbitrary style. Consider background-color, or border, or things like that. Explicit meaningless wrappers are sometimes necessary in CSS, and that's not going to change.
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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 Status: Rejected Change Description: no spec change Rationale: If the only reason is styling, then we should fix this in CSS. Requiring that authors wrap random parts of their documents in <div>s just so they can style them is a failure of the style layer and a layering violation. You shouldn't have to change the markup to get the look you want. Furthermore, this massively complicates the processing that tools would have to do to process lists. Right now it's very simple, you get the element and you walk its children. If we make the markup at this level arbitrarily complicated, it's going to cause all kinds of troubles. Another reason is that it's syntactically dangerous. Can you spot the mistake here? <ul> <li>... <li>... <div> <li>... <li>... </div> <li>... </ul>
(In reply to comment #8) > If the only reason is styling, then we should fix this in CSS. You are free to fix this in CSS (be it in 10 or 20 years), but, until this is fixed in CSS, this should be possible with currently available features. DIV insides lists are actually supported in browsers and should be just documented into spec. This is not something new, so nothing to be rejected. This is only formal validation issue. > Furthermore, this massively complicates the processing that tools would have to > do to process lists. Right now it's very simple, you get the element and you > walk its children. If we make the markup at this level arbitrarily complicated, > it's going to cause all kinds of troubles. I don't think so. Purely formal restriction is not something that helps web-developer who want that this restriction to not exist. This would be logical inconsistence. > Another reason is that it's syntactically dangerous. Can you spot the mistake > here? > > <ul> > <li>... > <li>... > <div> > <li>... > <li>... > </div> > <li>... > </ul> If list items have closing tags (they always do as for good web-developer), then there is no errors here. Again: current browsers already DO support wrapping list items in DIV, there is nothing to reject here, this should be just document into spec as actual current behavior of all current browsers. Thanks.
(In reply to comment #8) > If the only reason is styling, then we should fix this in CSS. Requiring that > authors wrap random parts of their documents in <div>s just so they can style > them is a failure of the style layer and a layering violation. You shouldn't > have to change the markup to get the look you want. 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. > Furthermore, this massively complicates the processing that tools would have to > do to process lists. Right now it's very simple, you get the element and you > walk its children. If we make the markup at this level arbitrarily complicated, > it's going to cause all kinds of troubles. That's absolutely true. I would not look forward to fixing the editing algorithms to handle this at all. > Another reason is that it's syntactically dangerous. Can you spot the mistake > here? > > <ul> > <li>... > <li>... > <div> > <li>... > <li>... > </div> > <li>... > </ul> Also a fair point. I'm okay with this resolution. Marat, if you're not, you should follow the instructions in comment 8 -- if you leave it resolved, Hixie won't even see your response. I don't recommend reopening it unless you have new arguments to present, though; you should either add the Disagree keyword or escalate to a tracker request.
See comment 9. CSS is a good thing (if it was publicly developed like HTML), but its' unlikely future improvements are not a reason at all to purely formally forbid using features that are already supported by real browsers and are only _formally_ disallowed by the HTML spec.
Ian, please consider responding _without_ immediate resolving.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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 Status: Rejected Change Description: no spec change Rationale: 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. There is no reason fixing this in CSS should take any longer than fixing it in HTML. 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. (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?
(In reply to comment #13) > (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? I guess it does, in the sense that scripts can always handle multiple things one-by-one with a little extra work rather than relying on a grouping element. This would be impractical if you had lots of complicated subdivisions, but that's implausible for a list, so the status quo is probably easiest overall.
(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 semantics. 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 invalid. >> 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): <style> UL {display: table; } UL > DIV {display: table-cell; } </style> <ul> <div> <li>first</li> <li>column</li> </div> <div> <li>second</li> <li>column</li> </div> </ul> 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.) Thanks.
(In reply to comment #13) Some additional thoughts. > There is no reason fixing this in CSS should take any longer than fixing it in > HTML. In fact, CSS has almost no progress as for features that are actually in-demand for _practicing_ web-developers who make websites (not specs) everyday. Good example is background-position-x/-y subproperties that are already implemented in IE and WebKit, but are not considered _theoretically_ reasonable by CSS authors. And this unfortunate trend is unlikely to change until then CSS spec development will became _public_ (like HTML5 development currently is). So, if HTML has already means for achieving a needed result, "we may fix it in CSS" cannot be an answer because we actually can't.
(In reply to comment #16) > (In reply to comment #13) > > Some additional thoughts. > > > There is no reason fixing this in CSS should take any longer than fixing it in > > HTML. > > In fact, CSS has almost no progress as for features that are actually in-demand > for _practicing_ web-developers who make websites (not specs) everyday. > > Good example is background-position-x/-y subproperties that are already > implemented in IE and WebKit, but are not considered _theoretically_ reasonable > by CSS authors. And this unfortunate trend is unlikely to change until then CSS > spec development will became _public_ (like HTML5 development currently is). > > So, if HTML has already means for achieving a needed result, "we may fix it in > CSS" cannot be an answer because we actually can't. CSS development is exactly as public as HTML is. Everything done in the CSSWG is done on public mailing lists or in public and logged IRC rooms. There is no significant difference in the development of HTML and CSS in the dimensions you mention. (This is irrelevant to the actual merits of this bug; it just bugs me when people assume that there's something magical about one spec group or another.)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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 Status: Rejected Change Description: no spec change Rationale: This is a presentational issue and should be handled in CSS. > 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. They have 10 times more market share than Opera, and we consider Opera important. > If a web-developer do care about semantics, then he always use closing tags. That's an incorrect assumption. > 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 > invalid. > >> > > That's all. That would be incredibly confusing to authors. It would also be a layering violation the content model of a document should not depend on the syntax used for it. We have been forced into that situation because of limitations of XML already, and it's not pretty. > Consider this example where list is multi-column (each div is separate column): > > <style> > UL {display: table; } > UL > DIV {display: table-cell; } > </style> > > <ul> > <div> > <li>first</li> > <li>column</li> > </div> > <div> > <li>second</li> > <li>column</li> > </div> > </ul> > > 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.) CSS multi-column layout is exactly how you solve the problem of multiple columns of layout. However, to answer your question without CSS multicolumn layout: <style>.a { float: left; clear: left; width: 10em; }</style> <ul> <li class="a">first</li> <li class="a">colunm</li> <li class="b">second</li> <li class="b">column</li> </ul> ...so that's two ways of doing it in CSS now. The point of splitting HTML markup and CSS styles is that you can then style the same markup multiple ways. If you're using <div>s to get the style you want then you can't do this. For example, take the markup you have above with the divs: now how do you put the first three <li>s into the first column and the last one into a second column, without changing the markup? The point is that if what you're doing is stylistic, then it shouldn't affect the markup at all.