[css-counter-styles] Change how 'pad' descriptor handles negative sign to match implementations

[xiaochengh]

The current spec says:

... If the counter value is negative and the counter style uses a negative sign, further reduce difference by the number of grapheme clusters in the counter style’s negative descriptor’s (s).

If difference is greater than zero, prepend difference copies of the specified to the representation.

However, it seems that no browser is doing this. They all prepend the pad symbol to the representation until reaching the specified length, and then add the negative sign.

For example, when using decimal-leading-zero (which has pad: 2 '0'), all browsers (I tested Chrome, Firefox, Safari) give -01, while the correct value should be -1 according to the spec.

Another example is WPT css/vendor-imports/mozilla/mozilla-central-reftests/counter-styles-3/descriptor-pad.html. Using an extension of upper-roman with pad: 3 *, the test expects -**I as the representation of counter value -1, instead of -*I.

Since all existing browsers are interoperable on a different behavior, I propose changing the spec to match the existing implementations.

[Loirooriol]

The padding doesn't take into account the prefix and suffix either, so it may be reasonable to ignore the negative sign too. I guess that the syntax of pad could always be extended in the future, so that authors can specify whether they want to include the prefix, negative sign or suffix.

[tabatkins]

I'd rather figure out if we can change browser to match the spec, first - I doubt there's compat impact, and the current specification is written the way it is for a reason: so both positive and negative numbers end up the same length, and thus (assuming a monospace font) the same width, which is the entire point of using the pad descriptor in the first place.

[tabatkins]

Agenda+ to confirm whether we're okay with leaving the spec as it is, or if we should adjust for bugwards compat.

[css-meeting-bot]

The CSS Working Group just discussed [css-counter-styles] Change how 'pad' descriptor handles negative sign to match implementations, and agreed to the following:

• RESOLVED: Leave the spec as it is and have browsers fix the bug

The full IRC log of that discussion

<dael> Topic: [css-counter-styles] Change how 'pad' descriptor handles negative sign to match implementations
<TabAtkins> Github: https://github.com/w3c/csswg-drafts/issues/5906
<dael> github: https://github.com/w3c/csswg-drafts/issues/5906
<dael> TabAtkins: It was brought up that browsers do not impl the spec with regards to pad descriptor and negative
<dael> TabAtkins: Pad is defined that if you have negative...pad 8 if your counter doesn't us 8 we pad it with more.
<dael> TabAtkins: If you have a negative sign we consider that part of counter value so add less pads.
<dael> TabAtkins: Intention is that assuming you use monospace fonts if you have positive or negative number you have same length of counter style representation
<dael> TabAtkins: Browers any negative value is longer than pad. Suggestion is change spec to current compat. I would prefer not to. I don't believe there's impl complexity there. Seems accidental. Doubt there's compat constraints
<heycam> q+
<dael> TabAtkins: If people agree like to resolve to not change and have browsers fix. Would like to hear if anyone disagrees
<dael> astearns: Anyone with preference to change spec?
<oriol> q+
<astearns> ack heycam
<dael> heycam: Question. Ad people using pad solely to make sure same number of characters for layout or also b/c wnat same number of digits for something semantic like an order number?
<dael> TabAtkins: If you're using counter mech to do semantic leading 0s you're really messing yourself out. I doubt it. Web is big, but not a supported use case
<astearns> ack oriol
<dael> oriol: No strong opinion on this. WOuld not mind no change. Seems a bit inconsistent to me. prefix and suffix can add content that is not counted for padding.
<dael> oriol: Maybe more consistent to say we don't include any of the extra things, prefix suffix or negative sign. Maybe in future authors can select which they want to include for generating padding
<dael> TabAtkins: Reason no prefix or suffix they're added unconditionally. Doesn't matter the value, they're added. You get the same for spacing regardless of value
<dael> TabAtkins: Also, prefix and suffix only added when done with default but negatives can be part of counter function. A little more important for that reason
<dael> TabAtkins: Main reason is negative sign is conditional and if you want a particular width you need to adjust for it
<astearns> ack fantasai
<Zakim> fantasai, you wanted to remind that padding with spaces is also possible, not just zeroes
<dael> oriol: Counter function not including prefix and suffix is good point. Fine with your proposal
<dael> fantasai: Reminding people you can pad with spaces as well. That's one case where you're going for layout consistency
<dael> astearns: I fecisiously asked if anyone was using padd, btu made me wonder if there are usage of pad that rely on current browser behavior and would no longer work with spec
<dael> TabAtkins: I doubt there are. I don't know of if there is measurable usage. I doubt there is a subset that requires a negative value to be one character longer
<TabAtkins> Padding with spaces.... don't work well with negative signs, fwiw
<dael> astearns: And fantasai your point about spaces I didn't get an idea as to if leaving spec changes it?
<dael> fantasai: Leaving spec is appropriate
<TabAtkins> `- 5`
<dael> astearns: Prop: Leave the spec as it is and have browsers fix the bug
<dael> astearns: Objections?
<dael> RESOLVED: Leave the spec as it is and have browsers fix the bug

[fantasai]

@xiaochengh The CSSWG discussed this issue in https://lists.w3.org/Archives/Public/www-style/2021Jun/0005.html and concluded on leaving the spec as-is for the reasons described by @tabatkins in https://github.com/w3c/csswg-drafts/issues/5906#issuecomment-770123158 (and the minutes). Let us know if this response is satisfactory!

[xiaochengh]

(Somehow missed this one...)

Thanks for resolving! The resolution looks good to me.