Re: [css-writing-modes-3] range limit for 'text-combine-upright: all' versus 'text-combine-upright: digits <integer>'

>>> “all” is only about scaling. We don’t limit, for instance, transform: scale() even if scale factor such as 1,000,000 won’t be used at all, right?
>>> 
>>> On the other hand, “digits" value has two effects; limits number of characters to apply, and when apply, it scales by 1em/width.
>> 
>> I understand that that's what they do. But why?
> 
> i suspect that one fundamental difference is that you might apply the digit setting to a whole paragraph or section, in which case you expect runs of digits to be automatically identified and made horizontal, but you want to avoid trying that on numbers that won't fit.
> 
> with the all value, you have to have manually specified boundaries, based on inline markup. This means that the content author is making the choice about how many characters it makes sense to fit horizontally on a case by case basis.
> 
> another difference is that applying character-based width counting to letters is more complicated that applying to numbers. 'Character' is only defined as equivalent to 'extended grapheme cluster' for section 5.1. So, for example, if you wanted to tate-chu-yoko a vietnamese word in NFD, you may apply the markup to, say, 12 characters, but only end up with 4 spacing character widths. Numbers don't include combining characters, so there's not the same question about whether the number of characters fits the width.
> 
> does that help?

It does, thanks. This is a good summary / reminder.

So for digits, the limit is not so much a matter of lack of use cases for more than 4 and of simplifying implementations, but actually about making it possible to apply to a whole paragraphs and avoid false positives. I had lost sight of that, thanks for the refresher.

Since 'all' is explicitly applied to just the right bit of markup, there are no similar false positive to avoid, and it's better to simply do exactly what the author asked for, and avoid surprising behavior, or complex (and potentially buggy) unicode handling.

The current behavior does indeed make sense.

 - Florian

Received on Wednesday, 24 June 2015 09:30:48 UTC