Re: [csswg-drafts] [css-counter-styles] Change how 'pad' descriptor handles negative sign to match implementations (#5906)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-counter-styles] Change how 'pad' descriptor handles negative sign to match implementations<br>
&lt;TabAtkins> Github: https://github.com/w3c/csswg-drafts/issues/5906<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5906<br>
&lt;dael> TabAtkins: It was brought up that browsers do not impl the spec with regards to pad descriptor and negative<br>
&lt;dael> TabAtkins: Pad is defined that if you have negative...pad 8 if your counter doesn't us 8 we pad it with more.<br>
&lt;dael> TabAtkins: If you have a negative sign we consider that part of counter value so add less pads.<br>
&lt;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<br>
&lt;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<br>
&lt;heycam> q+<br>
&lt;dael> TabAtkins: If people agree like to resolve to not change and have browsers fix. Would like to hear if anyone disagrees<br>
&lt;dael> astearns: Anyone with preference to change spec?<br>
&lt;oriol> q+<br>
&lt;astearns> ack heycam<br>
&lt;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?<br>
&lt;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<br>
&lt;astearns> ack oriol<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> TabAtkins: Main reason is negative sign is conditional and if you want a particular width you need to adjust for it<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to remind that padding with spaces is also possible, not just zeroes<br>
&lt;dael> oriol: Counter function not including prefix and suffix is good point. Fine with your proposal<br>
&lt;dael> fantasai: Reminding people you can pad with spaces as well. That's one case where you're going for layout consistency<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> Padding with spaces.... don't work well with negative signs, fwiw<br>
&lt;dael> astearns: And fantasai your point about spaces I didn't get an idea as to if leaving spec changes it?<br>
&lt;dael> fantasai: Leaving spec is appropriate<br>
&lt;TabAtkins> `-      5`<br>
&lt;dael> astearns: Prop: Leave the spec as it is and have browsers fix the bug<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Leave the spec as it is and have browsers fix the bug<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5906#issuecomment-853454815 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 2 June 2021 23:51:55 UTC