1545746 - Using counter-reset can break in-built list-item counters

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[brandonrbeck101]

Attachment: Screen Shot 2019-04-19 at 06.06.35.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Description:
Ordered list may receive an incorrect index/counter.

Scope:
Affects Firefox 68.0a1.
Tested on Mac and Firefox Android.
Issue does NOT affect Firefox 67.0b11

STR:
The bug becomes apparent when the following 2 conditions are met:

1. The CSS counter-reset property is set on an Ordered List <ol>
2. An Unordered List exists as a previous sibling to the ordered list, or its parent nodes (recursively)

---HTML--->

<style>
ol {
counter-reset:item;
}
</style>

Before an unordered list is introduced, everything seems normal.
<ol><li>Yields 1</li></ol>
<ol><li>Yields 1</li></ol>

<ul>
<li>However, An Unordered list causes subsequent Ordered list to have incorrect start indices</li>
<li>List items in the unordered list are counted twords the Ordered lists start index</li>
</ul>

<ol><li>Yields 3</li></ol>

<li>All list items between the ul and ol are counted</li>
<li>Even those not nested in ul/ol tags</li>

<ol><li>Yields 6</li></ol>

<div>
<ol><li>Yields 7</li></ol>
<ul>New unordered list reset or the index for subsequent ordered lists which are descendants of its parent node</ul>
<ol><li>Yields 1</li></ol>
<ol><li>Yields 2</li></ol>
</div>
Nested Unordered lists do not affect Ordered lists that come after their parent node.

<ol><li>Yields 8</li></ol>

<---HTML---<

Link to Example: https://codepen.io/anon/pen/KYRaRj

In the wild: https://mangadex.org/title/21562/kusuriya-no-hitorigoto/comments/

Actual results:

Ordered List that come before any unordered list have a start index of 1. Ordered list after an unordered list do not reset their indexes, and count all list items appeared inside and after the <ul>, but before themselves.

Expected results:

Every Ordered list should start from an index of 1.

Comment 1

[brandonrbeck101]

Description:
Ordered list may receive an incorrect index/counter.

Scope:
Affects Firefox 68.0a1.
Tested on Mac and Firefox Android.
Issue does NOT affect Firefox 67.0b11

STR:
The bug becomes apparent when the following 2 conditions are met:

1. The CSS counter-reset property is set on an Ordered List <ol>
2. An Unordered List exists as a previous sibling to the ordered list, or its parent nodes (recursively)

Comment 2

[brandonrbeck101]

Didn't realize the comment at the bottom of the page would be sent when I pushed the save changes at the top of the page. Ignore the duplicated text in the comment above.

Sorry about the formatting. Didn't remember markdown was supported until after creating the bug.

Comment 3

[Mats Palmgren (inactive)]

Attachment: Reporter's testcase

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2 (same test with <ol> replaced with <div>)

Comment 5

[Mats Palmgren (inactive)]

We have this in our UA sheet:

ul, ol, menu {
  counter-reset: list-item;
}

https://searchfox.org/mozilla-central/rev/d302c3058330a57f238be4062fddea629311ce66/layout/style/res/html.css#583
So by specifying ol { counter-reset:item } you are overriding
that and <ol> then behaves as an unstyled <div> regarding
the built-in list-item counter (as shown in Testcase #2).

If you want to have both counters you need to say so by using:
ol { counter-reset:list-item item }

This is how it's supposed to work according to the spec:
https://drafts.csswg.org/css-lists-3/#list-item-counter

Comment 6

[Emilio Cobos Álvarez (:emilio)]

If having rules with ol { counter-reset } is common, we may need to make that UA rule work like the list-item counter-increment I guess. But then you wouldn't be able to override it as an author...

Comment 7

[Mats Palmgren (inactive)]

Sure, but that remains to be seen. For now, I think we should stick
with what the spec says.

Comment 8

[brandonrbeck101]

I think I understand what your saying.
But I am confused then as to why the First 2 ol do reset.
Shouldn't the second ol should have an index of 2 in this case?
Why does ol reset the list-item counter before the first ul appears, but not after?

Comment 9

[Mats Palmgren (inactive)]

Attachment: Testcase #3, a 'foo' counter example

But I am confused then as to why the First 2 ol do reset.
Shouldn't the second ol should have an index of 2 in this case?

Each <li> has an implicit counter-increment: list-item. Given
that no list-item counter exist at that point, it's implicitly
created:
https://drafts.csswg.org/css-lists-3/#propdef-counter-increment

The second <li> isn't a sibling of the first one though, so it also
creates an independent new list-item counter.

Why does ol reset the list-item counter before the first ul appears, but not after?

It's not the <ol> that does that, it's the first two <li>s
themselves that does that. The <li> after the <ul> however
is a descendant of a sibling (the <ol>) of that <ul> so it
increments the counter that the <ul> created.

The built-in list-item counter behaves exactly the same as
any other CSS counter that you create in this respect.
Compare the 'foo' counter in this example.

Or this example:

<style>
  li { list-style-type: decimal; margin-left: 100px; }
</style>
<li>a
<li>b
<div><div><div><li>c

Comment 11

[Michael Müller]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

If having rules with ol { counter-reset } is common, we may need to make that UA rule work like the list-item counter-increment I guess. But then you wouldn't be able to override it as an author...

This at least affects the VisualEditor from MediaWiki, and thus Wikipedia and other wikis: https://phabricator.wikimedia.org/T229307

Comment 12

[Emilio Cobos Álvarez (:emilio)]

(In reply to Michael Müller from comment #11)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

If having rules with ol { counter-reset } is common, we may need to make that UA rule work like the list-item counter-increment I guess. But then you wouldn't be able to override it as an author...

This at least affects the VisualEditor from MediaWiki, and thus Wikipedia and other wikis: https://phabricator.wikimedia.org/T229307

Yeah, so this is a tough one... That could be fixed if we implemented that UA rule in C++ magically, by doing something like this (but with resets and a different condition of course).

The issue is, for list-item increments, you can specify an increment of 0, to "cancel" the built-in increment. For resets, there's no such thing :(

How likely is this to be fixed in MediaWiki? The fix is just specifying the extra counter name in counter-reset, and while so far we've only got this two reports, it's somewhat concerning...

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Given this appeared in some other site today, I've filed https://github.com/w3c/csswg-drafts/issues/4244 against the standard so it gets a broader look.