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 08:28:39 -0700
To: Koji Ishii <kojiishi@gluesoft.co.jp>
CC: W3C Style <www-style@w3.org>
Message-ID: <CE718784.D77C%galineau@adobe.com>


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

>> >You want to reject one optional behavior currently in the spec. James
>> >and I in this ML are against. Murakami-san was against as well if I
>> >remember correctly. Can you explain why you think we should reject the
>>behavior?
>> 
>> Which email of James are you referring to?
>
>James's first response[1], and the detail of how to implement[2]. I just
>figured out that he was convinced to include the John's behavior
>yesterday[3], but he still wants to have support for other font systems
>in different method[4], so this looks like a new proposal. I wrote this
>without reading James changed his mind yesterday.

I do not understand your interpretation of James' mail. I'll try again
later.

>
>
>> I can't make any sense of this compliance argument *at all*, and from
>> recent side discussions I'm not alone. Let's recap:
>> :
>> If 'Unicode compliance' were a requirement *and* implementors needed
>> alternatives then all these alternatives must be Unicode-compliant. We
>> can't both say CSS's role is to enforce some Unicode feature *and* tell
>> implementors it is conformant to ignore it.
>
>Ah, no, it's different from my intention. Maybe the English word
>"compliance" is stronger than I understand? I don't know which word is
>more appropriate...anyway.
>
>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. If different implementors want to do different
things then that constitutes an open issue and your job is to try and
achieve consensus on ONE solution. Now that you think James has proposed
something new, are you going to add a third option? Is that really how it
should work?

And if we're not sure we know what compliance means then maybe we should
stop using it as a crutch to justify anything and stick to feature design
and actual use-cases.

>
>Compatibility with Unicode (does this word work better?) is important
>because some developers are looking at UTR#50 and implement as is, and
>then find that CSS-compatible engines cannot call the API directly if
>UTR#50 behavior is not allowed in CSS. So behind it is implementers.

It doesn't change the argument. If we cannot remove one of the two
specified alternatives because the resulting spec would be incompatible
with Unicode then the remaining option is necessarily incompatible with
Unicode. If we can tell implementors it is conformant to be either
compatible with Unicode or incompatible with it then the spec does not
care about compatibility.


>
>Hope this makes sense.
>
>[1] http://lists.w3.org/Archives/Public/www-style/2013Sep/0830.html

>[2] http://lists.w3.org/Archives/Public/www-style/2013Sep/0769.html

>[3] http://lists.w3.org/Archives/Public/www-style/2013Oct/0011.html

>[4] http://lists.w3.org/Archives/Public/www-style/2013Oct/0013.html

>
>/koji
>

Received on Wednesday, 2 October 2013 15:29:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 October 2013 15:29:17 UTC