W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css-writing-modes] Tate-chu-yoko sizing rules

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 14 Jun 2013 19:02:07 +0900
Message-ID: <51BAEA1F.2050801@inkedblade.net>
To: www-style@w3.org
On 06/13/2013 09:34 AM, Koji Ishii wrote:
> I'd like to keep the current behavior as written in the spec.
> 
> I understand there're needs for several variations, but for this level,
> I'd like us to pick one behavior that is common, the most reasonable,
> the least problematic, and the most wide range of people accepts,
> even though it may not necessarily be the best for a segment of
> people.  We've been discussing to find such one for years by talking
> to several parties, and the current behavior is the one all agreed
> most reasonable.
> 
> There may be more findings than we had before, I'm a bit curious on
> that point, but what I found before was that, in general, uses/authors/
>publishers segments generally want to avoid conflicts. Printing and
> typographer segments don't care much of conflicts. Rather, they
> prefer conflicts than unexpected automatic behavior, but it is merely
> to find and fix errors easily. Either way, conflicts must be resolved
> before readers see the documents.
> 
> Given that, if we'd pick one default for this level, I think we should
> avoid conflicts. It may make some of professionals's tasks harder,
> but still doable, and it is acceptable for much wider stakeholders.
> 
> In terms of picking up 1/N glyphs, again, I'd like to keep the current
> definition--which is, undefined. We had this discussion before if I
> remember correctly, we actually had some words to specify the
> behavior in the spec, but removed them since there were some
> opinions including ones from implementers preferring it be left
> undefined. It allows implementations to use smarter technologies
> such as multiple master or iType. We may find even better logic
> after implementations. I can't find good reasons to revert the
> consensus at this point.

Okay, this works for me. :) I agree with all of your arguments.

> they prefer conflicts than unexpected automatic behavior,
> but it is merely to find and fix errors easily. Either way, conflicts
> must be resolved before readers see the documents.

I think this is an important point. Thanks.

~fantasai
Received on Friday, 14 June 2013 10:02:35 UTC

This archive was generated by hypermail 2.3.1 : Friday, 14 June 2013 10:02:35 UTC