This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html Multipage: http://www.whatwg.org/C#the-ol-element Complete: http://www.whatwg.org/c#the-ol-element Comment: Should ordered list numbering consider list items in child blocks? Posted from: 98.110.194.72 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/16.0 Firefox/16.0
Consider this testcase: <ol> <div><li>One</li></div> <li>Two</li> <li>Three</li> </ol> This is numbered "1, 2, 3" by Gecko, WebKit, IE7 and before, and IE quirks mode. It's numbered "1, 1, 2" by IE8 and IE9 standards modes and Presto. I'm pretty sure that at least for quirks mode pages depend on this behavior. I would also somewhat prefer that the behavior here not depend on mode... Note that for <ol reversed> this also raises the question of how the start value is computed.
http://w3c-test.org/html/tests/submission/Ms2ger/rendering/TODO-lists.html
This bug was cloned to create bug 18263 as part of operation convergence.
There's two questions here really. What the semantic number of the list items is, and what the rendered number is. For conforming documents in the absence of CSS, they should match. For the non-conforming cases, I don't really care if they match. Ideally I'd like to define the rendering purely in terms of CSS, but CSS doesn't yet support the logic for "reverse". Semantically, I'm fine with the <div> subtree being ignored and the nodes being "1" and "2". I'm not sure what to do in the meantime.
I'm going to mark this as a dupe of bug 17632, "Define rendering of <li> elements in terms of CSS". *** This bug has been marked as a duplicate of bug 17632 ***