- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 10 Mar 2016 16:14:57 -0500
- To: www-style@w3.org
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. ~fantasai
Received on Thursday, 10 March 2016 21:15:32 UTC