1672569 - counter-reset is not functioning correctly in version 82.0 (64 Bit)

This issue seems invalid per the resolution in https://github.com/w3c/csswg-drafts/issues/5477, but I'll let mats close it out in case he has other comments.

Severity: -- → S3

Priority: -- → P3

Hugo Dias

Comment 5

•

4 years ago

Another example of counter-reset being broken in 82 (firefox 81 didn't have this problem)

https://jsfiddle.net/Ly3bjmqc/25/

janet [:janet]

Updated

•

4 years ago

status-firefox82: affected → wontfix

Pascal Chevrel:pascalc (PTO until August 21)

Updated

•

4 years ago

status-firefox83: affected → wontfix

Dietrich Ayala (:dietrich)

Comment 6

•

4 years ago

Works as expected in Chromium and Webkit -> adding compat flags (hopefully right ones, cross fingers).

Keywords: compat, webcompat:needs-diagnosis

Clara Guerrero ( Need Info Brindusa Tot Please)

Updated

•

4 years ago

Has Regression Range: --- → yes

celebration.women

Comment 7

•

4 years ago

This problem is affecting files I maintain at "A Celebration of Women Writers".
http://digital.library.upenn.edu/women/
The pagination of the original book is tracked and displayed using a counter.
Depending on the book, the counter may be reset between the frontmatter
and the main section of the book, by "counter-reset: page 0; " (in the css file).
The counter is initiated by <body>.

This was working fine, but now the reset to 0 is not occurring.
As a result page numbers get messed up in the main section of text.
cf.
https://digital.library.upenn.edu/women/addams/hullhouse/hullhouse.html#1
The table of contents shows the expected page value at the beginning of chapter 1, which is 1;
what gets displayed is [Page 18], with subsequent pages also being offset by the difference of 17 pages of frontmatter.

I am using a Macbook Pro, running MACOS Catalina and Firefox 82.0.3 (64-bit),
The files are displaying fine in other browsers such as Chrome.

Mary Mark Ockerbloom, A Celebration of Women Writers

pesasa

Comment 8

•

4 years ago

It's not just nested counters, but also "linear" ones. The problem seems to be, that counter-reset resets the counter only for the current item, but not for following ones. The following items continue counting from the last value before resetting.

Simple example: https://jsfiddle.net/vr9ya7sz/

The example follows the idea of the CSS Demo in MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/counter-reset

Firefox 83.0 (64-bit) on Ubuntu 18.04.

Oriol Brufau [:Oriol]

Comment 9

•

4 years ago

(In reply to pesasa from comment #8)

It's not just nested counters, but also "linear" ones.

In these cases you should actually use counter-set instead of counter-reset.
It's not just counter-reset changed in Firefox, if you use counters() in Chromium then you get

1. One
1.6. Two
1.7. Three
1.8. Four

but most probably you didn't want to create a nested counter there.

Anyway, the change starts to seem not much web compatible.

pesasa

Comment 10

•

4 years ago

(In reply to Oriol Brufau [:Oriol] from comment #9)

In these cases you should actually use counter-set instead of counter-reset.
It's not just counter-reset changed in Firefox, if you use counters() in Chromium then you get

That's true. I noticed it after commenting.

1. One
1.6. Two
1.7. Three
1.8. Four
but most probably you didn't want to create a nested counter there.

Anyway, the change starts to seem not much web compatible.

Yes. What this shows, is that both Firefox and Chromium reset "nested counter with same name", but after that Firefox returns to use "outer" counter with counter(), but Chromium continues with the "nested" one.

Also, the difference between counter-set and counter-reset doesn't seem to be very well documented, for example in MDN. And Safari doesn't even seem to support counter-set.

Anje

Comment 11

•

4 years ago

Effects Thunderbird 78.5.0
bug 1636766
bug 1611861

Mats Palmgren (inactive)

Comment 12

•

4 years ago

(In reply to Anje from comment #11)

Effects Thunderbird 78.5.0
bug 1636766
bug 1611861

No, those bugs are about the old behavior that bug 1548753 fixed.

Mats Palmgren (inactive)

Comment 13

•

4 years ago

This works as intended per the updated CSS Lists spec.

Status: NEW → RESOLVED

Closed: 4 years ago

Flags: needinfo?(mats)

Resolution: --- → INVALID

Ryan VanderMeulen [:RyanVM]

Updated

•

4 years ago

status-firefox84: affected → wontfix

David

Reporter

Comment 14

•

4 years ago

(In reply to Mats from comment #13)

The comments listed in issue 5477 on github looks to refer specifically to the incorrect use of nested <ol><ul> 's. However, the bug impacts nested <section> elements as well. The use case in this example is large policy documents that have many text-heavy clauses and sub-clauses where-by using nested lists wouldn't make much semantic sense. From my understanding, the counter functionality is intended to count elements other than lists.

Firefox is the only browser where this numbering doesn't work as expected and only since v82. It's been over 2 months since first being reported. Is this likely to be fixed?

David

Reporter

Updated

•

4 years ago

Status: RESOLVED → REOPENED

Resolution: INVALID → ---

David

Reporter

Comment 15

•

3 years ago

Here's another example of the issue:

https://jsfiddle.net/vpgf39Lo/

If the current functionality in Firefox is working as intended - can anyone suggest how to better structure the above example? This works on all other browsers with the exception of Firefox.

David

Reporter

Comment 16

•

3 years ago

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

This works as intended per the updated CSS Lists spec.

Hi Mats,

If this functionality is intended, are you able to please suggest how to get this example working https://jsfiddle.net/vpgf39Lo/ ? I'm at a loss.

Mathew Hodson

Comment 17

•

3 years ago

(In reply to David from comment #16)

If this functionality is intended, are you able to please suggest how to get this example working https://jsfiddle.net/vpgf39Lo/ ? I'm at a loss.

It works if the <section> elements are nested like this:

<div class="test">
<section>
  <h3>This header should be 1</h3>
  <section>
    <p>This paragraph should be called 1.1</p>

    <h4>This header should be 1.2</h4>
    <p>Some dummy text within section 1.2</p>
    <section>
      <h5>This header should be 1.2.1</h5>
      <p>Some dummy text within section 1.2.1</p>
    </section>
  </section>
</section>
</div>

Then you can get the desired behaviour with CSS similar to the example at Using CSS counters.

.test section {
  counter-reset: section;
  margin-inline-start: 2rem;
}

.test section h1::before, .test section h2::before, .test section h3::before, .test section h4::before, .test section h5::before, .test section > p:nth-child(1)::before {
  counter-increment: section;
  content: counters(section, ".") " ";
}

David

Reporter

Comment 18

•

3 years ago

(In reply to Mathew Hodson from comment #17)

(In reply to David from comment #16)

If this functionality is intended, are you able to please suggest how to get this example working https://jsfiddle.net/vpgf39Lo/ ? I'm at a loss.

It works if the <section> elements are nested like this:
<div class="test">
<section>
  <h3>This header should be 1</h3>
  <section>
    <p>This paragraph should be called 1.1</p>

    <h4>This header should be 1.2</h4>
    <p>Some dummy text within section 1.2</p>
    <section>
      <h5>This header should be 1.2.1</h5>
      <p>Some dummy text within section 1.2.1</p>
    </section>
  </section>
</section>
</div>
Then you can get the desired behaviour with CSS similar to the example at Using CSS counters.
.test section {
  counter-reset: section;
  margin-inline-start: 2rem;
}

.test section h1::before, .test section h2::before, .test section h3::before, .test section h4::before, .test section h5::before, .test section > p:nth-child(1)::before {
  counter-increment: section;
  content: counters(section, ".") " ";
}

Thanks Matt, I think I'm still misunderstanding how to set this up semantically. I tried to extrapolate your example here: https://jsfiddle.net/5f43emr7/1/ but ran into issues.

I have several hundred legacy files to update for a client that were impacted from this Firefox patch, so any further help is greatly appreciated.

Mats Palmgren (inactive)

Comment 19

•

3 years ago

(In reply to David from comment #14)

(In reply to Mats from comment #13)

The comments listed in issue 5477 on github looks to refer specifically to the incorrect use of nested <ol><ul> 's. However, the bug impacts nested <section> elements as well.

This is an intentional change of how all CSS counters works. The CSSWG decided to change the spec to make the CSS counter scoping rules compatible with how HTML <ol><li> scoping works, so that it can be expressed as a built-in list-item CSS counter. The CSSWG was aware that this change would break some pages, but it was the least bad option available. Sorry for the breakage.

Firefox is the only browser where this numbering doesn't work as expected and only since v82. It's been over 2 months since first being reported. Is this likely to be fixed?

We have no intention of reverting this change. You should expect that other browsers will implement the new spec at some point.

Your examples are nested section counter scope so it's a bit tricky to make work under both the old and new rules, but it should be possible by using a separate counter on each nesting level, something like this:

.test {
  counter-reset: episode;
}
.test > section > section:first-of-type {
  counter-reset: chapter;
}
.test > section > section section:first-of-type {
  counter-reset: section;
}

.test > section h1::before,
.test > section h2::before,
.test > section h3::before,
.test > section h4::before,
.test > section h5::before,
.test > section p:nth-child(1)::before
{
  counter-increment: episode;
  content: counters(episode,".") " ";
}

.test > section > section h1::before,
.test > section > section h2::before,
.test > section > section h3::before,
.test > section > section h4::before,
.test > section > section h5::before,
.test > section > section p:nth-child(1)::before
{
  counter-increment: chapter;
  content: counters(episode,".") "." counters(chapter,".") " ";
}

.test > section > section > section h1::before,
.test > section > section > section h2::before,
.test > section > section > section h3::before,
.test > section > section > section h4::before,
.test > section > section > section h5::before,
.test > section > section > section p:nth-child(1)::before
{
  counter-increment: section;
  content: counters(episode,".") "." counters(chapter,".") "." counters(section,".") " ";
}


.test section {
  margin-left: 2rem;
}

.test section h1, .test section h2, .test section h3, .test section h4, .test section h5, .test section > p:nth-child(1) {
  margin-left: -2rem;
}

Status: REOPENED → RESOLVED

Closed: 4 years ago → 3 years ago

Resolution: --- → INVALID

David

Reporter

Comment 20

•

3 years ago

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

We have no intention of reverting this change. You should expect that other browsers will implement the new spec at some point.

Your examples are nested section counter scope so it's a bit tricky to make work under both the old and new rules, but it should be possible by using a separate counter on each nesting level, something like this:

Thanks for clarifying Mats, its good to know that other browsers will be also implementing the change in the future. I appreciate the extra detail - that helps a lot. I'll try using separate counters. I'm trying to avoid having to change the semantics of several hundred (large) documents, wish me luck!