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

On Fri, Mar 11, 2016 at 6:14 AM, fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 03/09/2016 11:07 PM, Koji Ishii wrote:
>
>> On Thu, Mar 10, 2016 at 6:36 AM, fantasai wrote:
>> >
>> > * We have an en unit. It does not change per writing mode.
>>
>> Where is it defined? I can't find in CSS Values[1]?
>>
>
> Sorry, my mistake. I was mixing up with "ex" unit.


"ex" is x-height, it's not a width...


> > * 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.
>>
>> Doing so doesn't solve what you want to solve, since it only solves for
>> digits.
>>
>
> It does solve it exactly for monospace fonts, and for tabular
> digits, and in fully proportional cases it's as close of an
> approximation as you can get. It's the best we can do, and
> it's needed to make the 'width' attribute of these elements
> work correctly.


All alphabets are likely to be proportional heights even for monospace
fonts. We intentionally left sythesizing height algorithm undefined IIRC,

Currently, WebKit/Blink on Mac synthesize it from bounding box, so "i" has
smaller advance than "k".

Blink on Windows and Gecko uses A+D for the advance of upright, but I've
got feedback from web authors that this is a bad behavior, so we might
change.

That said, there's no monospace upright fonts.

> 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".
>>
>>
>> I wasn't aware of that, if so, I'd request to change. This is too
>>  bad for authors, and makes things unnecessarily complex.
>>
>
> I've given the use cases for ch as defined in the spec.
> You still haven't given me a use case for ch as you prefer it defined.


Given above, I don't think it's a valid interoperable use case.

My use case is listed above; authors need something like "en".

> Not quite. A font with proper vertical metrics will not use
>> > a full em for the advance height of its ASCII characters.
>>
>> And such fonts will not work with the "ch" definition you're
>> proposing except for monospace digits. The solution is too
>> restrictive and makes little sense to me.
>>
>
> I don't see how your proposed definition improves anything.


It keeps "ch" constant, regardless of text-orientation, and that's what I
understand web authors want.

/koji