• Gecko 20100721
• Konqueror Version 4.4.5 (KDE 4.4.5), released 2010-07.
• WebKit 532.4; release date probably late 2009.
• Opera 8.02, circa 2005.
So they're not the most recent versions, but moderately recent other than Opera. I haven't tested any version of Internet Explorer or Prince.
I also tested a generic XML version of this document with each, except that I didn't know how to get Opera to render a generic XML document.
Basic case: two in-flow list-items in the same block parent, no other children.
OneTwo
Result: 1,2 in Konqueror and WebKit and Opera, while Gecko numbers each as 0.
Incidentally, Konqueror seems to force list-style-position:inside for all list-items other than <li> elements, even if I add an explicit list-style-position:outside (though I only tried adding an explicit list-style-position:outside for one of the tests). I don't mention this difference for Konqueror for most of the remainder of the test results.
Same thing but with lower-roman:
OneTwo
Result: Konqueror apparently considers this to be still part of the same list as the above, while WebKit and Opera consider it a new list (i, ii). Gecko displays as 0,0.
Second list-item is actually a child of an <em> (inline). So could be numbered one because it's the first child of the <em> element; though after anonymous block box processing, its parent box would be the <p>'s box just like each of the others.
OneOne or two?Two or three?
Result: Opera considers it part of the same list. WebKit considers the <em> to start a new, nested list. So at first this looks like it's going by the element tree [though given its results for some of the following tests that suggest a box-tree numbering, it looks like it's based on the box tree that would result without applying the 9.2.1.1 reparenting of the emphasized list-item]. Gecko of course numbers them all 0, as one would expect given its previous test results; while Konqueror of course considers it all the same list, just as one would expect given its previous test results.
Test of whether floated list-items are considered part of the same list as its non-floated siblings. The second list-item is floated, the other two aren't.
OneA float.Two or three?
Result: In Konqueror and Opera, no marker box and no apparent counter incrementing. WebKit was the same for the HTML version of this document, whereas in the XML version it does give it a marker box, and it's considered part of the same list. Gecko shows the marker box (with number 0).
This time, the float isn't a list-item but has a list item as a child.
OneA float.A list-item child of the float.Two or three?
Result: In Konqueror, the float child list-item is still part of the same list, and is numbered as per element tree; or as per box tree based on placeholder position. (Each of the other user agents of course considers the float child a separate list, just as one would expect given the behaviour for the other tests.)
Same as first float test, but the float now has list-style-type:disc, just in case this affects whether marker box is displayed.
OneA float.Two or three?
Result: Same as the first float test but with a disc instead of a number, in each user agent tested. Together with the above two tests, this suggests that float:right results in changing the display to block in those user agents, as if as a variation on section 9.7 rules (thouch I haven't checked with ecmascript). (Gecko displays the disc, as one would expect.)
Like the first float test but this time with position:absolute instead of float:right. Thus, it tests whether position:absolute list-items are part of the same list as the other two.
OneAbspos.Two or three?
Result: Konqueror and WebKit treat it as part of the same list this time, numbered between the two (i.e. as per element tree or box tree by placeholder position). Whereas Opera doesn't display a marker box or advance the counter. Gecko displays 0 as one might expect.
Like the above but list-item as child of the abspos, like the analagous float test.
OneAbspos.list-item child of the abspos.Two or three?
Results: Nothing interesting, each user agent displays as one would guess given its other test results. (So it's part of the same global list in Konqueror, it's a nested list in WebKit and Opera, and 0 in Gecko.)
Test whether list-style-type:none still advances the counter.
OneTwo-ishTwo or three?
Still advances the counter in Konqueror and WebKit. Opera is unexpected: no marker boxes in the whole list. Gecko is just as one would expect given its other results (no marker for the none item, while the other two are 0).
Same thing but with disc instead of none.
OneTwo-ishTwo or three?
Result: Still no marker box for any of this list in Opera. Other user agents are just as one would predict (each showing a disc for the middle item, advancing the counter in Konqueror and WebKit; and Gecko displays 0 for the other two items).
Test of :before list-item, whether or not it's part of the same list as its normal child list-item.
One or two?
Result: In Opera the two are considered part of the same list. In Konqueror, the before item displays no marker box and apparently doesn't advance the counter, so presumably is being forced to display:block (though I haven't queried with javascript). It is a list item in Gecko, with 0 as one would guess. The WebKit user agent I tried repeatably segfaults(!).
Two list-items separated by a table-cell, where the common parent element is table-row. This should result in the list items ending up in different anonymous table-cell boxes. So see if numbering goes by element parent (shared <p>, tending to favour same list) or box parent (distinct cells, tending to favour different lists).
OneCellOne or two?
Result: No marker boxes in Opera. Shared list in WebKit, so apparently going by element tree, or at least in a stage of the box tree before anonymous table object stuff is done, or ignoring the anonymous cell objects when determining list membership. While each of Konqueror and Gecko numbers as one would expect given its other results (shared global list in Konqueror, 0 for Gecko).
[Incidentally, not relevant to numbering, another rendering difference is that the cells are spaced in Opera (as if by a normal inter-word space) but not in Gecko and WebKit or Konqueror; so in Opera the text looks like "One Cell One or two?" while in Gecko and WebKit it looks like "OneCellOne or two?". As noted previously, Konqueror apparently forces all non-li list-items to list-style-position:inside, so in Konqueror the text looks like "28. OneCell29. One or two?".]
Our first test involving <ol> and <li>. The second <li> has display:inline, so the question is whether the <li> that follows will be numbered 3 (because it's the third <li> in its list) or 2 (because it's the second list-item in its list).
The fourth <li> is display:inline like the second, but has a pair of (non-<li>) list-item children. The fifth is the same as the fourth except that the <li> is display:block instead of display:inline, so there's a difference in anonymous block processing. The sixth is a normal item like the first, while the seventh is display:inline with an <ol> child that's actually display:list-item, containing a normal <li> child. While the final eighth <li> is a normal list-item like the first and sixth.
<li> containing a list-item and another list-item.<li> containing a list-item and another list-item.Result: Now Konqueror assigns the number 1 to the first li, so it's not part of the same global list that all our previous tests are using. The non-list-item li's don't advance the counter, so the third li is numbered 2. But its nested list (in the seventh li) behaves strangely: while one might expect it to begin a new nested list, it looks as if the ol list-item is getting 9 while its child li is getting 8! (It could instead be the other way round and unexpected marker placement; the text looks like "9. 8. Nested item.".) The eighth/final li is 10, as one might guess given that the seventh li's list-item children (including nested li) seem to belong to the top-level list.
In WebKit, the numbering seems to be by n'th list-item for a given ol ancestor (strictly ancestor: the list-item ol is considered part of its ancestor ol's list, while its child normal li is 1).
Gecko looks the same as WebKit but with two differences: the first is trivial, some extra vertical space above the nested ol, presumably due to different user agent stylesheet, though I haven't investigated; but the second difference is that the last li is numbered 10 for some reason: there is no 9. I don't know what's happening there. In any case, note that this test gives us our first non-zero numbers from Gecko.
In Opera, the non-list-item li's don't advance the counter (just as in Konqueror, WebKit and Gecko), and more generally is similar to WebKit, but with two differences: one is that the children of the display:block li are considered to be in a nested list; and the other is that the ol list-item marker and its child li's marker are superimposed.
Run-in test: a run-in containing an inline-block containing a list-item, that runs into a list-item. This is another test of box tree vs element tree: in the box tree, the run-in list-item is presumably considered to come after its ancestor list-item.
Run-in list item.List item that the run-in runs into.
Results: In Konqueror, numbering is continuing on from the above ol tree, so it seems that the ol acts as a reset as in counter numbering rather than starting a nested list. As would be consistent with list-style-position:inside, the text looks like "11. Run-in list item. 12. List item that the run-in runs into."
Opera is also a little strange, in that the run-in text is a couple of pixels higher than the run-into text. The two marker boxes (each numbered 1) are essentially superimposed other than those couple of pixels of y coordinate difference.
In WebKit, the two marker boxes are superimposed (with a slight blur that strongly suggests that there are indeed two distinct marker boxes as one would hope). Each is numbered 1.
For Gecko, each is numbered 0; the only thing of interest is that it isn't considered part of the above ol list, unlike Konqueror. The run-in does not run-in, but I believe this version of Gecko doesn't implement run-in [I believe because behaviour of run-in and its interactions with other features isn't very well specified yet].
Results for html { display:list-item; list-style-type:decimal; border:1px dashed blue; }:
WebKit and Opera allow root list-item, numbering it 1. Marker is outside border.
Konqueror allows root html element to be a list-item, numbering it 0, inside border as one would expect from Konqueror's apparent list-style-position:inside forcing.
Gecko doesn't display marker box for root list-item; I haven't yet determined whether this is a display issue or it's being forced to be display:block.