[css-counter-styles] range fallback is neither widely implemented nor sensible as specified #2479
Comments
Removing range from the stylesheets doesn't make sense; styles like Armenian are only defined over certain ranges. The rule can technically generate higher values, but it would just be total nonsense. If you wanted UAs to be able to do better than the specified range, that's something we could do with an explicit allowance, but the rule as written needs 'range'.
So what do you get when you do use a larger number than it's intended for? Just a really really huge representation? That seems like a bad thing to have happen by default. We also still need some rule for what happens when a counter style simply can't generate a representation for a particular value, like an additive style where all the weights are even (can't generate reprs for odd values). This falls back to decimal today, and I can't see any other possible way to do this. |
|
On Wed, 2018-03-28 at 13:05 -0700, Tab Atkins Jr. wrote:
Removing range from the stylesheets doesn't make sense; styles like
Armenian *are only defined* over certain ranges. The rule can
technically generate higher values, but it would just be total
nonsense. If you wanted UAs to be able to do better than the
specified range, that's something we could do with an explicit
allowance, but the rule as written needs 'range'.
Sure - you end up with really insanely long long values if you try & go
too much higher. I'm trying to explore ways to avoid falling back to
roman where it's not needed, e.g. by allowing better behaviour if a UA
knows how to count higher, in a way that won't cause backward compat
problems later if the stylesheets are extended to higher numbers and
people were relying on fallback to roman.
Adding higher numbers to Armenian actually looks doable with the
current rule if I understand Armeniannumbers correctly - the larger
numbers have a bar over them like medieval roman numerals - although
you still run out eventually of course, and have to have lots of
repeats, so it's not a solution.
We also still need some rule for what happens when a counter style
simply *can't* generate a representation for a particular value, like
an additive style where all the weights are even (can't generate
reprs for odd values). This falls back to decimal today, and I can't
see any other possible way to do this.
I can't either - as Henry Spencer said, if you lie to the compiler, it
will get its revenge. If the UA *can't* do better, if there's no right
answer, all the answers are wrong. Falling back to "number out of
range" in the user's language might be an improvement actually.
…--
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG
Improving Web Advertising: https://www.w3.org/community/web-adv/
Personal: awesome vintage art: http://www.fromoldbooks.org/
|
Again, we could allow that if we wanted with explicit callouts - we already do that with Hebrew (check the end of section 6.1), we just require that they reflect the expanded range correctly. However, it makes testing more difficult, for obvious reasons.
I strongly disagree that refusing to render at all is an improvement over just rendering in decimal. |
|
On Wed, 2018-03-28 at 13:28 -0700, Tab Atkins Jr. wrote:
> Adding higher numbers to Armenian actually looks doable with the
current rule
Again, we *could* allow that if we wanted with explicit callouts - we
already do that with Hebrew
Yes, i saw that.
However, it makes testing more difficult, for obvious reasons.
Yes, or easier, depending on what you test, but then there's a harder
burden on interop for sure. But the result may be a lot better.
> Falling back to "number out of
range" in the user's language might be an improvement actually.
I strongly disagree that refusing to render at all is an improvement
over just rendering in decimal.
i can see argument both ways, and also for [3901020 out of range] with
the number in roman if we cant' repreent it in the user's language,
which at least explains what's going on but will possibly break a
layout. But if it's relaying on unavailable numbers it's already
broken.
I'm not going to push back further - i wanted to try & avoid the
required fallback to arabic numerals. Actually, having said that, in
the case that the user's language isn't the same as the documents,
falling back to the user's number system might work too. For example, a
Japanese reader looking at an Armenian document could then see numbers
in Japanese. But it still doesn't help a Japanese speaker reading a
Japanese document in a browser that can't count high enough.
…--
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG
Improving Web Advertising: https://www.w3.org/community/web-adv/
Personal: awesome vintage art: http://www.fromoldbooks.org/
|
I would push back against that. This introduces a risk that authors may accidentally depend on the language of their computer to get the expected results, forget to language tag their pages appropriately, and then having the pages do "the wrong thing" when viewed from a different computer. Whether we always fall back to the same thing, or to something that's language dependent, I don't have a strong opinion. But if it is language dependent, it should be dependent on the language in the document, not in the environment. |
FWIW, Firefox support hebrew in [1, 999999], and complex CJK styles for the whole number range we can count (range of signed 32bit integer). And that is allowed by the spec. Also, CJK scripts fallback to And I agree with what @tabatkins said. If you are concerning that some counter styles may look weird when they go out of the range, someone can probably create something similar to |
|
@liamquin Falling back to decimal is far less disruptive than reporting an error. From the reader's perspective, decimal might look odd in certain context, but is fine: no information is lost. Error messages might be useful for authors, but not for readers--they are useless to harmful for readers: the reader doesn't care to see the message, but if it takes up unexpected amounts of space, then it disrupts the layout. As for why decimal, European numbers are practically universal these days. And as @frivoal writes, it's important for interop that we do not depend on OS language. |
|
On Thu, 2018-03-29 at 18:58 +0000, fantasai wrote:
@liamquin Falling back to decimal is far less disruptive than
reporting an error.
Fair enough. Sometimes commenting on github is more painful than a 5-
minute conversation. On the other hand i'd still like to see the UA
allowed (as per Hebrew) to go beyond 10,000 wihout resorting to
decimal, even if it complicated testing.
…--
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG
Improving Web Advertising: https://www.w3.org/community/web-adv/
Personal: awesome vintage art: http://www.fromoldbooks.org/
|
It is allowed, and at least Firefox does so, as I've mentioned in my previous comment. |
|
@upsuper yes, it's allowed for Hebrew and CJK. I'm asking that it be allowed for other languages. |
|
Both Hebrew and the CJK styles have the "UAs can implement higher if they want" because there is a reasonable way to number at least somewhat higher in those systems, it just doesn't have widespread agreement (CJK) and/or is complex (Hebrew). In both cases, particularly in CJK, I'd like everyone to implement the same range and have it specified in the spec. Other styles, based on my current knowledge, do not have a reasonable display strategy for higher values. Some can be done (anything additive), but it's doesn't produce reasonable results (a very very long Armenian string, for example). If someone has evidence of a higher range being reasonably supported in the wild, and can tell me how it works, I'm happy to adjust the spec to account for it. I'm not willing, however, to offer a blanket "or you can do whatever you want, if you think it's right" for values outside the range. |
|
@liamquin would you mind confirming if Tab's response is acceptable or not? |
|
Yes, it's acceptable, thanks. |
https://drafts.csswg.org/css-counter-styles/#counter-style-range
The range property falls back (eventually, through other fallbacks as needed) to decimal.
The normative stylesheet limits a bunch of languages to -9999 ... +9999, e.g. Armenian, and uses a single rule so that user agents are required to fall back to decimal. This is also true for Hebrew, Arabic, and CJK scripts, where roman decimal numbers don't use the same script (or direction?).
The range feature has practical uses that are helpful, but requiring that the UA fall back to roman numerals isn't one of them.
We have only one implementation of range, since only firefox implements @counter-style at all.
I propose
(1) change range so that it only falls back to explicitly mentioned fallback styles (so that you can chain rules, or say you want to fall back to Roman) - if you specify range without a fallback, the UA is to ignore the range property. You can still get the old (current) behaviour by specifying fallback to roman.
This will give some awkward results for numbers > 10,000 but see the next part of this proposal...
(2) remove range properties from the normative stylesheets and allow UAs to do better than 10,000
optional:
(3) move range and fallback to level 4, and stylesheet authors would just have to define numbering (or use predefined numbering) if they needed higher values - without requiring the UA to fail at 10,000.
(4) move the corresponding tests for range/fallback (maybe a dozen or so) to level 4
Of course, we still only have one implementation of the basic counter-style at-rule as far as i can tell, but this would simplify the spec, remove some tests that actually fail everywhere, and allow better results than the normative stylesheet allows.
The text was updated successfully, but these errors were encountered: