This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider the following markup: <ol> <li>foo</li> <li>bar</li> <li>baz</li> </ol> Suppose the user selects "baz", and does execCommand("indent"). The expected behavior (observed in all browsers, plus Word and OpenOffice.org) is for the second item to be indented into its own sublist. Opera 11.10 produces the following markup: <ol> <li>foo</li> <li>bar <ol> <li>baz</li> </ol> </li> </ol> IE9, Firefox 4.0, and Chrome 12 dev all produce this instead: <ol> <li>foo</li> <li>bar</li> <ol> <li>baz</li> </ol> </ol> Visually they're the same, assuming default styles. However, the latter DOM is more convenient to work with. Specifically, if the user now selects "bar" and does "indent" again, we want it to be indented to the same level as "baz", and do not want the indentation of "baz" to change, because the user didn't select "baz". With the IE/Firefox/Chrome output, this is easy: just move the whole <li> into its next sibling. With the Opera output, it's more complicated. It gets still more complicated if you have multiple children that are lists. So I'd really like to normalize any markup I get into the IE/Firefox/Chrome form, so that there are no lists that are children of <li>s, and then the rest of the algorithm is simplified considerably. Specifically, I'd like the content model of the ol and ul elements to become zero or more groups, each group consisting of a single li element followed by at most one ul or ol element. The items of the list should then be the li element children in tree order, except that if an li element is followed by a ul or ol element, that sibling should have the semantics of a list of sub-items (the same as if it were the last child of the li). I don't think it needs to be valid to have more than one ol or ul in a row, or to have one as the first child of a list, because I don't see any reasonable semantics to assign to those cases. I also have no opinion on the dl element here, since I don't have a use-case for changing its definition.
IE, FF and Chrome produce invalid markup here, that shouldn't be reason to change specs. Products should be fixed. Actually correct HTML representation is even different: <ol> <li>foo</li> <li>bar</li> <li> <ol> <li>baz</li> </ol> </li> </ol> which probably yields strange rendering results in this case, but that's different issue.
I explained why I think the spec should change here. The fact that browsers generate invalid code is not a good argument by itself -- execCommand() will realistically always generate invalid code in some cases, as a presentational API -- but I didn't use that argument. There's no reason the spec shouldn't change. Your code is not the same. <li>foo<ol><li>bar</li></ol></li> and <li>foo</li><li><ol><li>bar</li></ol></li> have different meanings. The first is a single item, which has a subitem. The second is two separate items, the first of which has no subitems and the second of which has no content except one subitem. I suggest the spec allow <li>foo</li><ol><li>bar</li></ol> as a synonym for the first case. That's what I'm having the execCommand() spec produce right now in this case, for the reasons I gave -- it's easier to work with for this use-case.
(In reply to comment #2) > Your code is not the same. <li>foo<ol><li>bar</li></ol></li> and > <li>foo</li><li><ol><li>bar</li></ol></li> have different meanings. The first > is a single item, which has a subitem. The second is two separate items, the > first of which has no subitems and the second of which has no content except > one subitem. I suggest the spec allow <li>foo</li><ol><li>bar</li></ol> as a > synonym for the first case. That's what I'm having the execCommand() spec > produce right now in this case, for the reasons I gave -- it's easier to work > with for this use-case. I still have troubles to understand reasoning behing this change. What would be meaning of <ol> acting as an item of list? If the meaning is that such <ol> is list item then why not to surround it by <li> and have clean content model for lists? If you are worried about additional bullet displayed in browser, then solution is to disable such bullet in stylesheet.
(In reply to comment #3) > I still have troubles to understand reasoning behing this change. What would be > meaning of <ol> acting as an item of list? As I said: (In reply to comment #0) > The items of the list should then be the li > element children in tree order, except that if an li element is followed by a > ul or ol element, that sibling should have the semantics of a list of sub-items > (the same as if it were the last child of the li).
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: The proposed semantics make my head hurt. I can't even imagine trying to explain to this authors. What we have now works fine; if you want an item to have subitems then you put them in the item, just like if you want an item to have two separate paragraphs you put them in the item, or if you want an item to have two paragraphs, two tables, two sublists, and a figure, you put them all in the item. It's the same model we use throughout the spec.
mass-move component to LC1