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

Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

From: Sylvain Galineau <galineau@adobe.com>
Date: Wed, 2 Oct 2013 09:06:18 -0700
To: Koji Ishii <kojiishi@gluesoft.co.jp>
CC: W3C Style <www-style@w3.org>
Message-ID: <CE718E37.D795%galineau@adobe.com>

On 10/2/13 8:42 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:

>> >It's implementers and implementers. On one side, two implementers said
>> >it's hard, so we added option B. On the other side, two implementers
>> >said they'd favor option A. One of them said he has already implemented
>> >option A.
>> I do not think your role as editor is to log every implementor
>>preference and spec it as an
>> alternative. It is a very bad idea for specs to offer implementors
>>equally conformant option
>> as this results in incompatibility for content and authors.
>I completely agree with your statement on the editor's role, and the
>second sentence as well.
>This is the case where all agreed that the incompatibility caused by the
>difference is very subtle, almost unnoticeable, and will be completely
>gone when user use the right fonts.

If this is such a small unnoticeable issue then specifying multiple
implementation options is massive overkill. I also fail to understand why
we'd want to suggest fallback behavior if we believe users will always
have the right font in the not-so-distant future.

One more thing: that someone already implemented one of these options is
not a valid motive to include it in the spec or keep it there. We do not
create implementation forks in a standard because someone did something at
the draft stage. 

>The costs to implement vary by underlying architecture. For one
>architecture, option A is much cheaper, while for another architecture,
>it's opposite.

The cost of UAs doing the same thing differently should be multiplied by
all the authors who will have to deal with it. You should consider the
overall cost of varying implementations, not just the cost to the tiny
number of people who implement it.

Also, if we believe implementors to be sensitive to implementation cost
then it's entirely reasonable to assume they will overwhelmingly favor the
option that does not include extra work i.e. they will not implement the
fallback behavior. That is also a good reason to question its necessity.

>Having two options help both implementers, while we lose almost zero,
>compatibility in the real world isn't sacrificed, only tests might fail,
>and some does care passing tests.

I completely disagree. Having multiple options to choose from does not
help implementors, not is it compatibility-neutral. It will  also require
more test cases since you need a set of tests for each conformant
alternative. It is more work for everyone; yet you argued earlier that
this is an subtle unnoticeable problem. Why would we want to increase the
cost of dealing with a minor issue?

>That is why I'm asking, why John thinks we should remove option A.

I think we have reached a pretty complete communication failure at this
stage, since so many of your arguments rely either on known design
anti-patterns or incoherent positions. I'll admit I'm 100% baffled here.


Received on Wednesday, 2 October 2013 16:06:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:33 UTC