Re: [css-values][css-writing-modes] ch and ic units

On Wed, Mar 9, 2016 at 1:36 PM, fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 03/09/2016 08:39 AM, Koji Ishii wrote:
>
>> On Wed, Mar 9, 2016 at 4:55 PM, Florian Rivoal <florian@rivoal.net
>> <mailto:florian@rivoal.net>> wrote:
>>
>>     I prefer "ch" always be the "width of "0" glyph, or 0.5em" as what
>>> authors lose looks more than what authors get.
>>>
>>
>>     Why is the width of the 0 character interesting if text is set
>> upright? If it is mixed or sideways, I agree width is the
>>     right measure, but for upright I don't see it.
>>
>>
>> For me, "ch" is an approximate unit that represents approximate
>> average width of Latin characters, and I expect it to be
>> 60-80% of "em", similar to what "en" does in non-CSS world.
>> It doesn't guarantee to fit any specific number of characters in
>> horizontal flow, so I don't expect it in vertical flow either.
>>
>
> Several points:
>   * We have an en unit. It does not change per writing mode.
>   * ch is an exact character count in monospace fonts
>   * ch is also an exact character count for tabular numbers
>     in proportional fonts.
>   * The use case for ch is an exact (for monospace fonts) or
>     approximate (for proportional fonts) sizing function
>     with respect to the number of characters that can fit on
>     a line. Its primary use case is <textarea>, <input>, and
>     <pre>. Ignoring the effects of text-orientation here would
>     make it fail at its primary use case.
>

I like to raise an issue here: a few years ago I made Pango's "average
character width" match something along these lines.  Then we got a report
from a browser implementation relying on that, having problems with
too-wide <input> and <textarea> under CJK locales.  The "exact character
count in monospace fonts" part is problematic for designers, as most
designers asking for, eg, 50ch in a textarea, do NOT want twice the width
for CJK...  In Pango, we ended up dividing that by something like wcwidth()
of characters to normalize CJK by dividing by two.

behdad


> Fwiw, the ch unit is already defined to be writing-mode sensitive,
> as the spec very intentionally uses the term "advance measure" and
> not "advance width".
>
> This was probably clearer when Writing Modes used the term "measure"
> to refer to inline sizes, so some clarification might help. However,
> the spec is nontheless unambiguous here, and any suggestion that it
> should use the advance width only would be a change both from its
> original intent and its current wording. I would not support such
> a change for the reasons mentioned above.
>
> If I were to think sizing by the number of ideographic characters,
>> the use of "em" is natural to me. And upright Latin is, for
>> me, ideograph-ized alphabets just like full-width alphabets.
>>
>
> Not quite. A font with proper vertical metrics will not use
> a full em for the advance height of its ASCII characters.
>
> ~fantasai
>
>


-- 
behdad
http://behdad.org/