- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Apr 2023 16:49:05 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-counter-styles-3] Should fallback use prefix/suffix of original style or fallback style?`, and agreed to the following:
* `RESOLVED: No change to current spec. Draft ability for a counter function to return the counter string including prefix/suffix, with various fallback options`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> TabAtkins: Issue here is, per spec, when you generate counter style for a marker<br>
<fantasai> ... it generates in your requested style, and adds prefix/suffix<br>
<fantasai> TabAtkins: but if there's fallback to a different style (beacuse given style can't generate that number)<br>
<fantasai> ... the algorithm doesn't pay attention to that fallback's prefix/suffix.<br>
<fantasai> ... It uses the prefix/suffix of the chosen style<br>
<fantasai> TabAtkins: I wrote it that way because simple, and because ability to even obtain prefix/suffix of a counter style is not accessible to author code<br>
<fantasai> ... so if we match to the prefix/suffix that was used to finally render<br>
<fantasai> ... authors wouldn't e able to manually reproduce that effect<br>
<fantasai> TabAtkins: However, it seems that browser do follow the fallback and use the prefix/suffix from the finally used counter style<br>
<fantasai> ... so have requested the spec to do that<br>
<vitorroriz> WebKit implementation is following current spec<br>
<fantasai> TabAtkins: If people want to change, then we can change the spec to have the prefix/suffix use the fallback style's prefix/suffix<br>
<fantasai> vitorroriz: WebKit follows the current spec, so not all browsers follow the other way<br>
<fantasai> vitorroriz: It came out from a bug report, but your sense about the counter API also makes sense<br>
<fantasai> TabAtkins: we can add more API to allow authors to do the same thing, if we want to<br>
<fantasai> TabAtkins: but it does seem that FF and Chrome do follow the fallback, and WPTs match that<br>
<fantasai> jensimmons: This might be a good time to do what's right for authors<br>
<fantasai> ... Safari hasn't had support for counter styles, so once we ship it could become a lot more populare<br>
<TabAtkins> fantasai: My concern with changing the spec is you'll end up with an inconsistent prefix/suffix if you're falling back<br>
<emeyer> fantasai: My concern with changing the spec is that you’d end up with inconsistent prefix/suffix when falling back<br>
<TabAtkins> fantasai: Say your number system doesn' thave negatives, and you use () as your prefix/suffix<br>
<ntim> q+<br>
<TabAtkins> fantasai: And if falls back to decimal whihc has period as its suffix<br>
<TabAtkins> fantasai: you'll switch styles when you fallback, functionally<br>
<TabAtkins> fantasai: Feel like it would make more sense to keep the prefix/suffix consistent across the list<br>
<TabAtkins> fantasai: even if your system is limited in some way<br>
<TabAtkins> fantasai: So I think the spec behavior makes more sense form a usage pov<br>
<TabAtkins> fantasai: I udnerstand from an impl it can be easy to just gen a string from another style<br>
<Rossen_> ack ntim<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to ask about use cases<br>
<fantasai> ntim: Looking at WPT, it seems that Chrome matches safari, not Firefox<br>
<emilio> q+<br>
<dholbert> q+<br>
<Rossen_> ack emilio<br>
<fantasai> emeyer: When jfkthame changed this, he had a strong opinion that it was the right thing to do<br>
<fantasai> s/emeyer/emilio/<br>
<fantasai> emilio: If we resolve not to change, we should check in with him<br>
<fantasai> dholbert: Wrt fantasai's example, it was for someone using 2nd/3rd/4th, using letters as a suffix<br>
<fantasai> ... and trying to use the appropriate suffix there<br>
<fantasai> ... in which case it's quite reasonable to use the suffix from the fallback<br>
<Rossen_> ack dholbert<br>
<Rossen_> ack fantasai<br>
<TabAtkins> right, `counter(ordinal)` would still just produce a number from that counter style<br>
<fantasai> fantasai: It seems that that person is tryng to create a numbering system<br>
<fantasai> ... but the prefix/suffix is only a formatting applied to counters when rendered as a list-item marker, specifically<br>
<fantasai> ... doesn't work in other uses<br>
<fantasai> ... seems that it should be built into the number *value* if it's part of the number, not part of the formatting prefix/suffix<br>
<fantasai> TabAtkins: a) To build this in yourself, you'd have to do it as an additive system... which would probably work just as well?<br>
<fantasai> TabAtkins: but aside from that, this is the reason why it makes sense to have a counter() variant that produces the full representation rather than just the number value<br>
<fantasai> ... so that authors can reproduce what authors are doing automatically in list-item<br>
<fantasai> TabAtkins: I would like it if authors can reproduce the functionality in API, so if we resolve to change should update API<br>
<fantasai> TabAtkins: I don't have a strong opinion on which way to go<br>
<TabAtkins> @counter-style ordinal { system:additive; additive-symbols: 900 "9", 800 "8", ..., 90 "9", ..., 9 "9th", ..., 1 "1st"; }<br>
<TabAtkins> actually that's way shorter than what the bug reporter was trying to do<br>
<fantasai> fantasai: I feel like if we want to support ordinal numbering, we should build that into the value of the counter<br>
<fantasai> ... so I lean no change<br>
<fantasai> ???: I tend to agree with fantasai, we should provide appropriate API<br>
<fantasai> ... but might be a bit awkard if we don't<br>
<Rossen_> s/???/vitor/<br>
<fantasai> jensimmons: Building examples, there's numbering in Ethiopic which uses a suffix based in the language<br>
<fantasai> jensimmons: It's confusing that prefix/suffix applies only to list items<br>
<vitorroriz> I also think that we should just change it if a counter() variant api is provided to enable authors to access the fallback prefix/suffix<br>
<fantasai> TabAtkins: that's a legacy issue, counter function has always worked this way<br>
<fantasai> jensimmons: It does feel like prefix/suffix works with the number<br>
<fantasai> jensimmons: feels unnatural<br>
<fantasai> TabAtkins: I can see both ways<br>
<fantasai> TabAtkins: whatever way we decide the default, when we create function, could make it optional<br>
<fantasai> TabAtkins: then if what the default's doing, they can do themselves<br>
<fantasai> jensimmons: So keep existing legacy stuff simple and add something more powerful?<br>
<Rossen_> ack fantasai<br>
<TabAtkins> value-prefix/value-suffix descriptors? and maybe with some more functionality to tie it to numeric value. something for counter-styles-4<br>
<fantasai> fantasai: I think the current prefix/suffix feature is reasonable to exist<br>
<fantasai> ... this is so that list-item counters format properly, and those prefix/suffixes should not be emitted in counter()<br>
<TabAtkins> proposed resolution: no change from current spec, but add a counter-tbd() function that generates a string *with* prefix/suffix (exactly what fills ::marker by default) with a choice of using original or fallback prefix/suffix.<br>
<fantasai> fantasai: but it might also be helpful to have a prefix/suffix feature that represents some segment of the number rendering itself<br>
<fantasai> ... that's a different feature, and we have a bit of a name clash, but it's a different feature that maybe should also exist<br>
<fantasai> ... and in that case, it's a bit more complicated, because the prefix/suffix can depend on the *value* of the counter<br>
<TabAtkins> (oh, and put some notes in calling this behavior out)<br>
<fantasai> ... and is an essential portion of the stringification of the number<br>
<fantasai> TabAtkins: [reads out proposal]<br>
<jensimmons> and I'd add that the new thing works in lists, and elsewhere counters are used.<br>
<Rossen_> ack fantasai<br>
<emeyer> fantasai: I’m not 100% sure about whether that’s going to make sense once we have proper support for ordinal numbering<br>
<emeyer> …Not sure if you’d want to switch, but maybe you do<br>
<emeyer> …If you prefix and suffix are characters, would you actually want to follow the numeric pattern<br>
<emeyer> …I think we might want to investigate further how to do ordinal numbering<br>
<fantasai> TabAtkins: That's a harder problem, but we still need the formatting string version of the function<br>
<fantasai> ... so I think we should do it anyway<br>
<Rossen_> q?<br>
<oriol> q+<br>
<fantasai> Rossen_: Any further thoughts or objections to the resolution?<br>
<Rossen_> ack oriol<br>
<fantasai> oriol: So the new function, could it be for the `content` property, or for list-style-type, or ... ?<br>
<fantasai> TabAtkins: atm, define it as exactly equivalent to counter() and counters() but with slightly different generation for the string<br>
<fantasai> ... so these should be usable as <string>, if the browser supports it; but would definitely be allowed in 'content'<br>
<fantasai> oriol: so it wouldn't be for list-style-type<br>
<fantasai> TabAtkins: no, it's not a new counter type. Just a new string-generating function<br>
<emeyer> fantasai: Maybe an argument to the existing function?<br>
<fantasai> Rossen_: OK, hoping this answers the question. DIdn't hear any objections<br>
<fantasai> RESOLVED: No change to current spec. Draft ability for a counter function to return the counter string including prefix/suffix, with various fallback options<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8619#issuecomment-1523747123 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 April 2023 16:49:07 UTC