Reported on https://webcompat.com/issues/29737

The mininal test case

data:text/html,<ol><li><a href="">item 1</a></li><ul><li><a href="">subitem 1.1</a></li><li><a href="">subitem 1.2</a></li><li><a href="">subitem 1.3</a></li></ul><li><a href="">item 2</a><ul><li><a href="">subtitem 2.1</a></li></ul></li><li><a href="">item 3</a></li></ol>

Every browsers prior to Firefox 68 displays 1. 2. 3.
Since Bug 288704, Bug 205202 and Bug 1518201, it displays 1. 4. 5.

Chrome, Safari, Edge and Firefox 68 (before Sun Mar 24 22:14:10 2019 +0000) displays 1. 2. 3.

The regression window gives
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5dc0652cd024fef30217ac3e6087b7a32f16967f&tochange=9bad25ccc8d0414e21d3c8d4dcf2178a97bb07c3

The 'list-item' counter is now implemented using the same algorithms as
any other CSS counter such as 'foo'. So the original testcase renders
as expected -- this is just how CSS counters works. Chrome renders
the 'foo' testcase the same as Firefox. (The value of the "4" item is
really "1.4", which you can see if you switch counter() to counters().)

As Karl noted in the webcompat issue:

The markup is wrong. The first ul should be inside li.

I agree that's likely what they intended.

The question is if we want to invent some special counter algorithms for
the list-item counter that are incompatible with other CSS counters.
I tend to think we should try to avoid that, unless faulty markup like this
is widespread. It's inevitable there will be some breakage though, but I'm
hoping other vendors will also implement the [css-lists] spec soon.

Alternatively, we could consider changing the css-lists spec.
I get the impression that the rather peculiar rules around counter scopes in that section was intended to match how legacy HTML lists works to allow them to be implemented using a list-item CSS counter.
David, do you know if that is the spec author's intention?

Here's a testcase to illustrate the differences.

Fwiw, here's a WIP to make CSS counters behave as HTML:
https://hg.mozilla.org/try/rev/ad6245954694ac19aad6881278696bfbaaf20d24

(In reply to Mats Palmgren (:mats) from comment #4)

Alternatively, we could consider changing the css-lists spec.
I get the impression that the rather peculiar rules around counter scopes in that section was intended to match how legacy HTML lists works to allow them to be implemented using a list-item CSS counter.
David, do you know if that is the spec author's intention?

Sorry for the delay in replying.

My memory is that the constraints that led to the counter scope rules being what they are were roughly:

• support numbering traditional HTML headers (h1, h2, ..., h6), new-style HTML headers (section and h1), and HTML ordered lists (ol and li), for valid HTML markup
• use the counters() function to generate numbers like "3.2.7" for the second and third of those cases
• do that with only counter-reset and counter-increment (since counter-set hadn't been invented yet, so there was no way to set a counter's value without creating a scope)
• support the value attribute on li (using counter-reset!)
• not have any cases where appending new content to the end of a document (i.e., incremental loading) could change any numbers earlier in the document. (This was not true in CSS 2.0, but the rules were revised to do this in 2.1.) This required that creating a new scope not affect earlier (in depth-first traversal order) content.

A bunch of the rules changed pretty substantially (particularly to meet the last constraint, and to make things clear that were previously not clear) when I provided a lot of spec feedback while implementing counters in Gecko.

but some of this was only tested in the spec author's heads since actual implementation for list items didn't happen until very recently.

... and note that the idea was that some elements could have their behavior implemented using pseudo-elements, e.g., the counter-reset for ul being like it's on ul::before rather than on ul.

When this bug can be fixed? Please at least fix the basic rendering issue for 1570809.

Given that there are duplicates, should this still be P3?

Fwiw, there's a recent Chrome bug open on re-implementing their list ordinals here:
https://bugs.chromium.org/p/chromium/issues/detail?id=990657
and there's been some questions about how the default list-item counter
works in various spec issues from Google folks, which I read as interest in
implementing it as a CSS counter too.

Sean and I discussed this issue and we decided to leave it as is for now.
It seems this isn't a wide-spread problem, nor affect any major web sites,
but we'll keep a lookout for new web-compat reports, and also see what
the Chrome folks decide to implement.

Also, this message has some pointers that should lead to a bunch of the counter discussions in 2005.

Looks like this also popped up on Stack Overflow recently (as reported in #layout on IRC):
https://stackoverflow.com/questions/57566925/firefox-html-ordered-list-numbering-messed-up-by-sublist

(Copy my comment from 1574398):

If putting <OL> directly under another <OL> is invalid, then Firefox should not generate such structure when call execCommand("indent");

<div contenteditable>
<ol>
<li>1</li>
<li>2</li>
<li>3</li>
<li>4</li>
<li>5</li>
</ol>
</div>

<button onclick=test()>test</button>
<script>
function test() {
document.execCommand("indent");
}
</script>

Put cursor at "3", then click the button to run execCommand("indent"), Firefox will change the structure to

<ol>
<li>1</li>
<li>2</li>
<ol>
<li>3</li>
</ol>
<li>4</li>
<li>5</li>
</ol>

And in fact, Chrome, IE, Edge have the same behavior for execCommand("indent"), but only Firefox shows wrong number. Then if user creates the content from other browser with <div contenteditable> then show in Firefox, it is still wrong.

(In reply to jisong from comment #19)
I think that's fair.

Indeed, but that's a separate issue. I found bug 525888 which appears to be about that so I added the testcase there.

I think it's also fair to point out that execCommand is essentially deprecated.
The draft spec says:

This spec is incomplete and it is not expected that it will advance beyond draft status. Authors should not use most of these features directly, but instead use JavaScript editing libraries.

(In reply to Mats Palmgren (:mats) from comment #15)

Sean and I discussed this issue and we decided to leave it as is for now.
It seems this isn't a wide-spread problem, nor affect any major web sites,
but we'll keep a lookout for new web-compat reports, and also see what
the Chrome folks decide to implement.

Hi Mats.

In case of tools like our Siemens Polarion ALM, this issue is much more severe than you think. Our rich-text editor based on GWT and native browser functionality is producing such problematic markup natively. Users of our software are authoring and consuming specifications of safety critical systems, such as cars, planes, or peacemakers. Having wrong list numbers in lists that are a very natural part of specifications may lead to mistakes in interpretation and therefore to life-threatening hazardous situations.

Please be aware that with the move of enterprise software to web-based solutions and cloud, implications of issues like this are getting more and more serious. And as much as the issue is not crucial for generic web audience, it is very critical for enterprise users leveraging enterprise software to develop products that everyone uses every day like cars, computers, mobile phones and all sorts of other smart appliances.

Best regards,
Radek Krotil
Siemens Digital Industries Software
Polarion ALM Product Management

Working, as I do, at microsoft, I find myself spending a lot of time using Azure DevOps (formerly known as Visual Studio Team Services (formerly known as Visual Studio Online (this is where I lose track but you get the idea))). There's a project we have, roosterjs, that gets used in situations much like this one, it provides rich text editing for work items, bugs, features, etc. I've been tracking this bug over there regarding the way their list numbering works on firefox at the moment. That bug links over here to bugzilla, but I'm not quite convinced that responsibility for fixing the issue leaves our hands there.

It looks like the roosterjs library uses execCommand() to actually do the indentation operation that produces the invalid html, and the spec for execCommand() seems to present a fairly strong case against itself. I'm not super engaged with the js community (I make my home further towards the bottom of the stack), so when the spec suggests instead using "javascript editing libraries," are there some things I should be looking for to replace our usage of execCommand()?

Makoto tells me that the change to execCommand to avoid generating the invalid markup should be easy to do. Since we don't want to change how list numbering works (I think?), and there is some site breakage here, maybe we should consider changing execCommand to avoid getting into this situation. Masayuki, WDYT?

Yeah, of course, I'd like to fix it if other browser vendors also fix it.

However, it might not be easy to fix. While I'm working on bug 1574852, I saw a lot of code which assume that sub-list is always created in another list element without list-item element.

I would like to point out that it is not just invalid html markup that exhibits this behavior, the following code exhibits the incorrect list numbering in firefox but not in ie or chrome:

<style>ol { counter-reset: list; }</style>
<ol>
	<li>Item 1
		<ol>
			<li>sub item 1 (firefox 69 shows as 2)</li>
		</ol>
	</li>
</ol>

I may be mistaken but I do not believe FF 67 was exhibiting this behavior and now FF 68 and up are.

(In reply to eric from comment #29)

I would like to point out that it is not just invalid html markup that exhibits this behavior, the following code exhibits the incorrect list numbering in firefox but not in ie or chrome:
[...]
I may be mistaken but I do not believe FF 67 was exhibiting this behavior and now FF 68 and up are.

That is a different issue which can be fixed by using counter-reset: list list-item, see bug 1545746. That's working as per spec but I filed https://github.com/w3c/csswg-drafts/issues/4244 about it to discuss.

I'd like to understand why this regression caused in FF 68 hasn't been fixed. Why have versions 68, 69 and 70 been marked "fix optional"?

This simple HTML page displays correctly in FF below 68, IE, Edge and current Chrome.

I came here from bug 1585047 where a Thunderbird 68 user complained about the issue. This will affect thousands of TB users when we roll out TB 68 (and reflect badly on the product and Mozilla).

Mats, are there reasonable changes that we could make to the counters algorithm that we could make here in order to produce the compatible behavior here?

I guess we could change the CSS Lists spec, the text regarding counters from previous siblings specifically, so that it's compatible with this invalid HTML case. But that would break existing (author-specified) CSS counters that depend on the current algorithm. I don't think it's reasonable to add a special case for the built-in list-item counter. Given the same counter-set/reset/increment values, list-item and an author-specified foo counter should result in the same counter value IMO. To avoid that, we could extend the spec to allow either behavior and then make the UA sheet for HTML <ol> etc use the new behavior by default.
So the alternatives I can think of are:

1. no change
   Pro: all counters behave the same + no spec changes
   Con: regression for invalid HTML (as reported in this bug)
2. change CSS Lists to make all CSS counters behave differently for this case
   Pro: fixes this regression
   Con: spec changes + breaks existing (author-specified) CSS counters (possibly with worse fallout)
3. tweak the behavior of the built-in list-item counter only
   Pro: fixes this regression
   Con: spec changes + the built-in list-item and other CSS counters behaves differently which is a more complicated model to implement, specify, and teach to authors
4. extend CSS Lists to allow either behavior
   (e.g. something like ol, ul, menu { counter-reset: strict-scope(list-item); } in the UA sheet)
   Pro: fixes this regression
   Con: spec changes + a more complicated model to implement, specify, and teach to authors

Personally, I think option 3 is unreasonable because I want all CSS counters to behave the same, given the same declarations.
Option 2 doesn't seem reasonable either since it would break existing content (not just invalid markup!).
I guess we could investigate option 4 to see it's possible to implement, assuming the CSSWG would be willing to amend the spec with that change.
Personally, I still think option 1 is the most reasonable option since it's only invalid HTML markup that has changed behavior.
It's unfortunate that execCommand("indent") produce invalid HTML markup but I intend to fix that (should have patches for that ready in a few days). The main concern here seems to be for contenteditable/editors and I believe the underlying issue there is indeed execCommand("indent"). With that fixed, I'm not sure the fallout here is severe enough to justify option 4.

Just adding that this issue is mentioned on Twitter, they discovered it in Gmail.
https://twitter.com/help4innovators/status/1186835843521990656

AIUI Mats is looking into fixing editor in bug 525888 for that kind of use case.

(In reply to Mats Palmgren (:mats) from comment #15)

Sean and I discussed this issue and we decided to leave it as is for now.
It seems this isn't a wide-spread problem, nor affect any major web sites,
but we'll keep a lookout for new web-compat reports, and also see what
the Chrome folks decide to implement.

Contrary to this update, this IS a wide-spread problem. For example, we have text editors in our platforms to let users submit their tickets. Now we have to explain non-tech users why their list numbering is not working. The worst thing is that their seems no workaround for the end user and we have to tell them to resort to Chrome.

As for the execCommand, I see that the ticket bug 525888 was opened 10 years ago but hasn't showed any progress in terms of fixing it or providing any alternatives.

I understand that you might be doing the right thing here following the spec, but you ought to implement it only after every other vendor agrees. Otherwise it is only harming Firefox's user base.

I see the status as fix-optional for the Firefox version 69 and 70. Can somebody point me to the fix? I'm not able to find out.

Thanks
A Firefox proponent for 7+ years

Please consider fixing this bug anyway, even though non-compliant HTML is at fault.

We have a use case that has not been mentioned yet: Most of our webpages are created/maintained be people using Microsoft Word, which produces non-compliant ordered lists, as described above. These pages render correctly in IE and Chrome but in Firefox have the unexpected numbering. It is not feasible to manually tweak every page when updated and saved anew, nor to get Microsoft to comply with specs. (Unless enough of us band together and make a ruckus.)

Please consider this approach: in the face of non-compliant HTML, what is the "best" thing to do? In this particular case, why not treat the </ol> tag of the nested list as "closing the context" of that list? Simply discard the counter for that list. In other words, if you were to remove everything from the nested <ol> to </ol>, including the tags, how should the resulting ordered list be rendered? The presence of the nested ordered list should have no effect, malformed or not.

THANKS for listening.
Another long-time Firefox proponent, and exclusive user except under duress.

(In reply to Matt Read from comment #43)
Actually, is there any chance you could you tell me how to repro the issue you're having with lists in Word? I can try to raise the issue to the right team, see if I can't cause enough of a ruckus to get some eyes on it at least.

Thanks for the quick reply! I am using MS-Word 2016 and a generic text editor for the following steps:
Create a simple (raw) text file with this content (similar to previous posts above):
<html><body>
<ol>
<li>should be 1
<ol>
<li>should be 1</li>
<li>should be 2</li>
</ol>
</li>
<li>should be 2</li>
</ol>
</body></html>

Note that w.r.t. the <ol> and <li> tags, this is spec-compliant, i.e. the nested list is fully within the containing <li>/</li> pair. This file renders as expected in Firefox: the "should be 2" item is indeed numbered "2".
Now open that file in Microsoft Word, and simply save it, using the default save-as file type: "Web Page (*.htm, *.html)". Give it a distinct name if you want.
The new file renders with "should be 2" having the number "3".
Inspect the source of the Microsoft-created file and observe that the <li>/</li> tagging has been reworked, specifically such that the <li> for the first "outer" list item is terminated with </li> before the <ol> tag for the "inner" list.
Here is the relevant snippet (newlines retained):
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in'><span style='mso-fareast-font-family:
"Times New Roman"'>should be 1<o:p></o:p></span></li>
<ol start=1 type=1>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level2 lfo1;tab-stops:list 1.0in'><span
style='mso-fareast-font-family:"Times New Roman"'>should be 1<o:p></o:p></span></li>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level2 lfo1;tab-stops:list 1.0in'><span
style='mso-fareast-font-family:"Times New Roman"'>should be 2<o:p></o:p></span></li>
</ol>
<li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1;tab-stops:list .5in'><span style='mso-fareast-font-family:
"Times New Roman"'>should be 2<o:p></o:p></span></li>
</ol>

Also note: when creating nested numbered lists natively in Word, then saving the doc as .html, Word does not use <ol> and <li> tags; it uses simple <span> tags hard-coded numbers and with MS-internal tags to facilitate edits/updates. So this behavior pertains to the scenario where an existing HTML document is opened/edited by a Word user. Around here that is the main sequence.

Thanks. Hope this helps. Sorry for the post length.

This image shows the terrible effects currently being applied to creating lists in Thunderbird version 68.8.0.

Note the following rules are observed. This represents a serious misunderstanding of how lists work and has been rolled out in version 68.

Rule 1: Where no indents at all, the top level numbering is contiguous and correct.
Rule 2: Where only one indent from top level number to top level upper case letter, the number of letters is converted into number equivalent and that number is shown as next top level number and has no relationship to actual top level numbering. Hence why a top level 3 can be followed by top level number 7 (see bottom of list).
Also Where there is more than one set of indents (2 or more), and outdenting to another indent that is not a top level indent, then same applies.

Rule 3: Where there have been two (or more) indents and now performing the last outdent to return to top level. No matter what the letter, the number of item in list will have a minus one applied.
examples: 3rd in indent list will be converted to top level number 2. 4th in indent list will be converted to top Level number 3.

This means it is currently impossible to create any lists that are more than a simple top level list.

Problem....<li> line is closed using </li> when an indentation <ol> follows, but it should close after the close of the closed indentation </ol>.

Image shows When email saved as .eml, edited so that lines with indentation are not closed prior to indent. Then count in display of list is fixed.

eg:
Thunderbird currently creates as follows and therefore display is all over the place.

<ol>
<li> one </li>
<li>two</li>
<ol>
<li> indent one </li>
</ol>

edit as follows to fix display.
<ol>
<li> one </li>
<li>two
<ol>
<li> indent one </li>
</ol>
</li>

Supplying info as seen and experienced in Thunderbird.

(In reply to Mats Palmgren (:mats) from comment #35)

Personally, I still think option 1 is the most reasonable option since it's only invalid HTML markup that has changed behavior.
It's unfortunate that execCommand("indent") produce invalid HTML markup but I intend to fix that (should have patches for that ready in a few days). The main concern here seems to be for contenteditable/editors and I believe the underlying issue there is indeed execCommand("indent"). With that fixed, I'm not sure the fallout here is severe enough to justify option 4.

Do we need to re-evaluate what we do here given that the execCommand fix doesn't appear to be moving forward due to web compat concerns, per comments in bug 525888?

I think it's worth evaluating option 2 from comment 35 more seriously -- I think there's likely not enough direct usage of counters for the compatibility issues with such a change to be worse than this bug. (I could be wrong, though -- but my previous impression was that counters aren't that widely used.)

Not resolved.

It appeared to be resolved when I created a list
1
2
3
-
-
4
5

But then, when I realised that I should have made 4 a sub-bullet of 3, indented it and changed it to a bullet, 5 remained 5.

So I tried to cut the text from 4, press "enter" after the second sub-bullet to create a third, and paste the text without formatting, then delete 4. But 5 remained 5, and counted that bullet as a number.

When I then went into the bullets, pressed enter to create a new bullet, and out-dented it to a number, again it assumed that the previous sub-bullet was a number.

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

Is this bug on the docket ot be fixed?

This looks like this in the email editor:

1. One

   1. One point one
   2. One point two

2. Wut?

3. One

   • One sub one
   • One sub two

4. Seriously?

(In reply to rosangela.manfredo from comment #63)

Is this bug on the docket ot be fixed?

Yes, see comment 57.

Is there any suggested fix, though?

I'll take a look and see if I can find a solution...

Hi all
A related issue that may have a bearing on your implementation here: when replying to a message with quoted text, if I break an ordered list then I get silly behaviour, eg if replying to

On Friday 23 Jan, Blah wrote:
| 1. first
| 2. second
| 3. third

Like so

On Friday 23 Jan, Blah wrote:
| 1. first
Hey! I wanted to add a comment
| 1. second
| 2. third

Maybe this is a whole different thing, but if this is requiring major surgery then perhaps it might make sense to consider this issue at the same time.

Cheers

Can this be fixed? Just make a list showing correct number will be good enough. All other browsers don't have this issue. And older version of Firefox also working fine.

<ol>
<li>This is 1</li>
<ol>
<li>Sub 1</li>
<li>Sub 2</li>
</ol>
<li>This should be 2, but Firefox will show as 3, it is WRONG!!! </li>
</ol>

https://treeherder.mozilla.org/#/jobs?repo=try&revision=71962f12b8816051616e478589e745a9347cf024

https://hg.mozilla.org/mozilla-central/rev/755595716629

Comment on attachment 9171617 [details]
Bug 1548753 - [css-lists] Prefer an ancestor's counter scope over a sibling's scope. r=emilio

Beta/Release Uplift Approval Request

• User impact if declined: Given that this broke some existing content, I think it's worth consider merging this fix to beta to get it fixed sooner. We have a pref to disable the change in case it causes any unexpected regressions.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:

Comment on attachment 9171617 [details]
Bug 1548753 - [css-lists] Prefer an ancestor's counter scope over a sibling's scope. r=emilio

Given that this isn't a new problem, I'd feel better letting this bake longer and ride the 82 train to release.

Effects Thunderbird 78.5.0 - been wrong since version 68.8.0
bug 1636766
bug 1611861

Reports that it is not working in FF 82
bug 1672569

Should this bug be reopened or closed and continued in bug 1672569 ?

(In reply to Anje from comment #81)

Effects Thunderbird 78.5.0 - been wrong since version 68.8.0
bug 1636766
bug 1611861

This is expected since this bug was fixed in version 82, and not a reason to reopen.

Reports that it is not working in FF 82
bug 1672569

This is a different bug, one that's a regression from this one. Also not a reason to reopen, unless this one is reverted.

When is this fix supposed to land to Thunderbird?
When starting to nest lists all numbers get screwed up, making numbered lists completely unusable in Thunderbird (tested with 78.7.1).

It's fixed in beta/nightly. Will be in the next major release, 91, scheduled for July.

Same issue still occurs with the latest version of Thunderbird (78.12.0) - Nested Ordered Lists are entirely unusable.

I too am (still) having the same problem with the latest version. The problem is not just with nested ordered lists; the failure also occurs with an unordered list nested in an ordered list, e.g

1.) ppp
2.) qqq

• rrr

2.) sss