FF82 CSS counter-reset spec fix

[hamishwillee]

counter-reset has this example on the top. The results from Chrome, Firebox 81 and earlier, and everything else are on the left, the results from Firefox 82 are on the right.

All of those chapters are h2 headings, and the counter-reset is applied to the second chapter "The pool of tears". In the context of just this example you'd think that the Chrome was correct and that the subsequent items should follow the siblings, but in fact it is in violation of spec.

The reason is that each element gets a copy of the counter(s) of it's ancestors "first" if a counter is not explicitly applied. When you call counter-reset on an element you reset the counter on that specific element (create a new counter), not on every other (subsequent) elements (from comment in bug).
So while the selected counter should change, the other siblings keep their original counter.

This might seem odd, but normally you'd call counter-reset on the parent, not on some arbitrary element mid way through.

To get the more intuitive behaviour we're seeing in chrome you could call counter-set. My understanding is that this would set the counter on the element and on all subsequent elements in the same scope, though I could be wrong [ @MatsPalmgren could you confirm all that? i.e. both counter-reset and set statements ]

Anyway, as this is a spec fix I have done this as a "negative subfeature", meaning that use_reset_for_siblings has been added as a deprecated subfeature that reflects the non-spec behaviour from the first version. This is still supported by Chrome et al, but Firefox has version_removed from FF82. Eventually all things should match the spec, and this would eventually be removed.
I called this use_reset_for_siblings which I hope is a reasonable name for the bad behaviour, with description "Reset counter used instead of ancestor for subsequent sibling elements."`, Maybe better name would be "counter_reset_affects_siblings"?

FYI

1. This follows on from CSS Counters - Explained the differences in browsers behavior with respect to CSS Counters. content#13513 - I want to confirm that I have the problem well understood before I review and update that.
2. The example used in image above is also problematic and a fix has been proposed by Mats in Issue with "counter-reset": the example is a bit confusing interactive-examples#2793. I'll get to that eventually.

@ddbeck Thoughts? I really want @MatsPalmgren advice too. This is an ongoing source of confusion.

[ddbeck]

I think I have a suggestion here, but I want to make sure I understand completely. Here's the story (but correct me if I'm wrong):

1. By the specification, counter-reset creates ("instantiates") a new counter on the selected element.
2. Excluding Firefox 82 and later, counter-reset modifies an existing counter at the selected element, if the named counter already exists.

This suggests two things:

• Excluding Firefox 82 and later, counter-reset affects the same-named counter of subsequent siblings.
• Excluding Firefox 82 and later, counter-reset and counter-set do the same thing.

Have I got it?

[hamishwillee]

Have I got it?

I think so, but the story is all messed up in multiple threads. Which is why I asked for feedback from @MatsPalmgren

[queengooborg]

Hey @hamishwillee, what's the status of this PR?

[hamishwillee]

@queengooborg Arrrrgggg. This PR adds a "negative subfeature" indicating some off-spec behaviour that was fixed in FF82 but which is still wrong on all other browsers. Daniel left this approved so I could merge it when/if I like. But I have been waiting on @MatsPalmgren to confirm my understanding. He is silent. I wonder if there is another way to ping him.

So we could merge this if you like as "likely to be correct" and certainly more correct than the last version. But you take a different view on negative subfeatures than Daniel, so perhaps you'd like that changed? I vacillate between liking and disliking them.

FYI CSS counter reset is a minefield of misunderstanding; this was supposed to to be the mechanism for confirming how it all works.

[queengooborg]

Let's go ahead and merge this as-is -- could we update this to use the mirror value on applicable browsers (Chromium Android forks and Safari iOS)?

[hamishwillee]

@queengooborg OK. I decided to make this a normal (not reversed) feature and apply mirroring. So now the feature looks like this.

"reset_does_not_affect_siblings": {
          "__compat": {
            "description": "Resets counter on current element (not sibling elements).",

In some ways this is more clear and concise. What firefox does is apply a reset to the current element, which will affect the element and any children it has (as they will get a counter seeded from it). However the other siblings are not reset - they keep the counter that they were given when their ancestor was created.

This should be "good" now.

[queengooborg]

Thanks, this is LGTM!