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

I have no idea what makes you so emotional. Did I say something impolite or illogical?

Your opinion is not to have two options, I understand that, but which?

1. We accepted John's proposal to move text-orientation:mixed to Unicode two years ago.
2. John then said Tr is hard to implement for him, tiny tailoring will make it much easier.
3. Another implementer said John's proposal is hard for him, requested to stick to Unicode.

Both are the same arguments, just opposite, and the numbers of supporters are coincidentally the same as of today.

I agree with you as general rules, but in this specific case, I do not see a good way to pick one, nor anything anyone would lose by allowing both.

John already mentioned that users and authors will not know the difference.

You're right implementers need to spend time on choosing which implementation s/he would take, but the cost return will pay the time s/he spend to choose.

I can write a test that both implementations can pass. I haven't done it yet, but I know how to do it and I'm hoping to write it in some TTWF.

Well, if you're talking only about general rules but not this specific case, I completely agree with you, sorry that this discussion must be a noise to you.

-----Original Message-----
From: Sylvain Galineau [mailto:galineau@adobe.com] 
Sent: Thursday, October 3, 2013 1:06 AM
To: Koji Ishii
Cc: W3C Style
Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'



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.

>
>/koji
>

Received on Wednesday, 2 October 2013 16:44:27 UTC