[css-lists] Is the list-item counter increment for list items reflected in the computed style?

[emilio]

@domenic raised this potential interop issue. Edge supports the list-item counter, but doesn't expose it in the computed style.

Reading https://drafts.csswg.org/css-lists/#declaring-a-list-item:

(This has no effect on the values of the counter-* properties.)

I read it as "shouldn't be exposed in the computed style". But @MatsPalmgren disagrees with this (https://bugzilla.mozilla.org/show_bug.cgi?id=1539171#c3).

Given this requires some magic already I tend to think it shouldn't be exposed in the computed styles, though Mats thinks it's better.

Could this be clarified?

[MatsPalmgren]

I disagree that getComputedStyle should lie about the actual value of any of the counter-* properties.
I see no benefit to anyone in doing that and I also don't think it's needed for web-compatibility.

[MatsPalmgren]

BTW, what the initial value of the counter-increment property is has already been resolved (recently) in issue #3686 (for those that didn't see that).

[fantasai]

@emilio I think your reading of the spec is correct, at least, I think that's what it intends. What it should say being a separate question. :)

@MatsPalmgren Gecko implementers in particular have told use repeatedly that they dislike cross-property dependencies for computed style, so it's interesting that you want the opposite thing here? Fwiw I think I agree with @emilio that this shouldn't be exposed. It's an implied increment unless you make it explicit.

[MatsPalmgren]

@fantasai dependencies on display is not a problem - we have a lot of those already ;-)

What you say about the intention seems to contradict what @tabatkins said in #3686 (comment) "When you need to interact with the list-item counter explicitly, the code you write under (A) is identical to what you'd write if list-item was just set up in the UA sheet, or in an author sheet."

Since the resolution was (A), that's how we implemented it (by synthesizing a computed value), since that's basically "set up in the UA sheet" (with the selector "display is list-item").

[fantasai]

@MatsPalmgren I think the distinction here is whether it gets synthesized at computed-value time or used-value time. Certainly by used-value time, that's what we should have.

[MatsPalmgren]

#3686 is explicitly about the initial value - it even says so in the subject. So I don't see how the resolution can be interpreted in any other way than being about the computed value. (You are of course free to reverse that resolution here, but I don't see why given that it's less than two weeks ago it was discussed).

Fwiw, I don't feel that strongly either way. I just think a computed value is a more honest way to do it. It makes it explicit for authors to see rather being something magic that happens at used-value time, unless they specify an increment. Also, a computed value makes it possible to inherit (not saying that's a particularly useful feature or anything, just that "it works normally" is nice).

[fantasai]

@MatsPalmgren The issue was about that, but the discussion covered what happens on non-initial values. @dbaron's summary of the options in #3686 (comment) is pretty clear about that. Fwiw, I don't feel too strongly about used-value vs computed-value time; if there's a good reason to go with one vs the other it's fine with me.

[emilio]

I don't like to add code to the generic "fixup the style" mechanism that deals with all the dependencies between properties, but that's a bit of a personal preference in this case since as mats noticed we have plenty of other dependencies on display already. So I don't think there's a great argument for one against the other either...

Biggest argument for used-value time would be backwards compat. However the risk doesn't seem terribly high here (unless proven otherwise of course).

It does feel weird that you have a computed value that you cannot override changing the specified value except overriding the counter again... It's a bit more magic than usual. But again that's a bit subjective.

Maybe @lilles has any opinion from the Chromium side? I just noticed https://bugs.chromium.org/p/chromium/issues/detail?id=946176 was filed not long ago.

[css-meeting-bot]

The CSS Working Group just discussed Is the list-item counter increment for list items reflected in the computed style?.

The full IRC log of that discussion

<dael> Topic: Is the list-item counter increment for list items reflected in the computed style?
<dael> github: https://github.com//issues/3769
<dael> emilio: There's a magic increment applied to list items that's defined in terms of display. Element with display styling you have the magic counter increment depending on if list is incremented [missed]
<dael> emilio: Another possible thing to do is to just do it at used value time
<dael> emilio: I don't feel too strongly either way, maybe other engines have constraints on when can shuffle elements. As an author don't know if it's very useful to gCS with this counter. If you spec counter-incremeent:none and computed style is not none
<dael> fremy: I think it's not included in counter style
<fremy> ^ (in Edge)
<fremy> ^ (which is good because it probably should not inherit)
<dael> AmeliaBR: Clarification. When author says counter-increment:none it doesn't cancelt he list item incremement. Based on rule serialization should be as short as poss if omitting list item 1 have same effect as spec shouldn't shortest version be to omit it?
<emilio> Ugh, audio went nuts
<dael> plinss: Looks like emilio is having audio issues. Still there emilio ?
<dael> [silence]
<emilio> on irc yes
<dael> plinss: He's IRC only at this point
<dael> plinss: Any other thoughts on this?
<emilio> We could also do what AmeliaBR mentions, but that is only ommittable depending on the display value, so it's a bit weird to serialize differently depending on other property values
<emilio> fremy's point about inheritance is a good point
<dael> plinss: Should we defer until emilio can be on a call? He's responding on IRC
<dael> gregwhitworth: Let's defer if he's not able to get one
<dael> s/one/on

[css-meeting-bot]

The CSS Working Group just discussed Is the list-item counter increment for list items reflected in the computed style?, and agreed to the following:

• RESOLVED: implicit list-item counter is not reflected in computed style

The full IRC log of that discussion

<dael> Topic: Is the list-item counter increment for list items reflected in the computed style?
<dael> github: https://github.com//issues/3769
<dael> emilio: I think fremy point is good. weird the counter would be inherited
<dael> AmeliaBR: You're agreeing the implicite list item shoudln't show in computed styles?
<dael> emilio: Yes. That's what I prop. Mats disagreed.
<dael> plinss: Wondering if we have right people to resolve this
<dael> fantasai: My incl is leave as a hidden mech but I don't have strong rationale. I'd choose that unless there's a good reason to reflect in CS. Putting it in CS means it inherits which is a little werid
<dael> fremy: Another reason is right now it's a breaking change but if you don't put in computed style it's not a breaking change. UNless there's a strong reason for it to be in computed style it shouldn't be
<dael> emilio: I don't think in this case compat is a constraint but I agree it's nice to keep compat
<dael> AmeliaBR: Sounds like call agrees. Resolve it pending a clear objectionsfrom Mats or anyone?
<dael> plinss: sgtm
<dael> plinss: Objections?
<dael> RESOLVED: implicit list-item counter is not reflected in computed style