W3C home > Mailing lists > Public > www-style@w3.org > March 2016

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 10 Mar 2016 16:14:57 -0500
To: www-style@w3.org
Message-ID: <56E1E3D1.4040103@inkedblade.net>
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.

> > * 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.

> > 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.

> > 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.

Received on Thursday, 10 March 2016 21:15:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC