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



On 9/27/13 9:38 PM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:

>Yeah, ok, let me try as short as possible, and skip all technical details.
>
>> I do not think this is a good characterization of John's position.
>> No one wants to prohibit 'Unicode-compliant implementations',
>> as far as I can tell, nor is a 'fork of the Unicode spec'
>> suggested.
>
>I agree. My point is that, if we accept his proposal, although his
>intention is different, it'll be in-compliant to Unicode as a result. And
>John is not responding to that point.

I don't understand what is 'in-compliant to Unicode' or even why it's even
relevant here. I'm specifically asking for technical feedback from the
implementor you've referred to. What could Unicode compliance could
possibly have to do with that?

>
>> John was also an implementor and a member of this WG
>
>Yes, of course. A very important implementer. That's exactly why we allow
>tailoring as he requested.
>
>Here's the simplified picture.
>
>We got two different requests from two different implementers, so we
>allow both. I believe this is fair.

Dude, for the nth time: you are being asked *why* the other implementor
wants things to work differently. Until this is addressed I do not believe
these two 'requests' are equivalent.

Second, 'fair' is irrelevant. The priority is to specify the right feature
for authors and for content; specifying optional behavior for the dubious
benefit of keeping two implementors happy is thoroughly sub-optimal.
You're more likely to keep one or both of them equally frustrated, at
best; as for authors, optional behavior typically means incompatibilities,
which is clearly not fair to them.
>
>Now one of them wants to prohibit the other. That "the others" are in a
>different group, and the group supported them.
>
>Isn't it more natural for him to talk to the group?

About as natural as it would be for that other implementor to talk to this
group. Since you know who that is - right? - that would save everyone a
lot of time. 

At the end of the day the feedback to you is that specific technical input
is needed to resolve this issue. Without it I suspect you'll be appealing
to Unicode authority a while longer.


>
>/koji
>
>-----Original Message-----
>From: Sylvain Galineau [mailto:galineau@adobe.com]
>Sent: Saturday, September 28, 2013 12:58 AM
>To: Koji Ishii
>Cc: W3C Style
>Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr'
>codepoints in 'text-orientation'
>
>
>
>On 9/27/13 6:25 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:
>
>>Yeah, I agree in general. But in this specific case, it's more complex.
>>The optional behavior is to save costs, and what John is asking is
>>adding costs.
>>
>>John's point, if I understand correctly, is about value v.s. cost. He
>>understands it has values very clearly, but he thinks the value is tiny
>>that it's not worth for him or his organization to spend the cost for
>>the value. That's fine with me, we added an optional behavior to allow
>>simpler implementations.
>>
>>Now that in this proposal, John wants to prohibit Unicode-compliant
>>implementations. This is problematic.
>>
>>First of all, this is about a behavior defined in Unicode. For whatever
>>reasons, I'm strongly against invalidating Unicode spec in CSS spec. We
>>could add optional behaviors, but any Unicode-compliant implementations
>>should be CSS-compliant as well if we refer their spec. This helps
>>layered architecture work well and save costs.
>>
>>For example, if Turkish uppercasing isn't worth for some implementers,
>>they don't have to implement. We make it optional. But we do not
>>prohibit implementers to follow Unicode spec if doing it is worth for
>>his/her organizations. Even if it's not worth, if the implementation is
>>using external libraries such as ICU, it comes free. In this case,
>>it'll cost more to disable the behavior defined by Unicode.
>>
>>Second. This is about what UTC has resolved to publish; REC in W3C world.
>>UTC allows members to speak about group resolutions, but do not allow
>>to expose who said what. Agree or not, that's how they manage the
>>organizations, and I believe it is their method to help more active
>>discussions under their circumstances.
>>
>>Given this, discussions about their resolutions, especially when it's
>>not about technical correctness but about whether the implementation
>>cost is worth the value or not for who, will be very limited and
>>difficult to do outside of the UTC. It may be because some members have
>>already implemented that way. But still, if it's published, it's
>>supported by full members[1], because all resolutions must go through
>>full members voting process. At least more than half of the full members
>>must agree.
>>Note that I'm not part of the voting, because Rakuten, my company, is
>>not a full member but just an associate member.
>>
>>So if John thinks it's not worth to everyone on the planet, he should
>>raise his objection to Unicode, and should ask to change their spec.
>>I'm fine for him to do that if he wants to.
>>
>>If he thinks it's not worth for him or for his organization, he should
>>ask CSS WG to add an optional behavior. He did that, accepted, and
>>we're here now.
>>
>>But prohibiting Unicode-compliant behavior in CSS is a different story.
>>We've never done that before as far as I know. It creates a fork of
>>Unicode spec, it's a disrespect to Unicode, and it adds more cost to
>>some other UA implementers. I can't find any values in doing so other
>>than tiny subtle interoperability of orientation for a couple of code
>>points in some specific fonts.
>>
>>/koji
>>
>>[1] http://www.unicode.org/consortium/memblogo.html

>
>Koji,
>
>FWIW as a relative outsider in this debate - I do not know anywhere near
>enough on this topic to have a strong opinion - I do not think this is a
>good characterization of John's position. No one wants to prohibit
>'Unicode-compliant implementations', as far as I can tell, nor is a 'fork
>of the Unicode spec' suggested. (It's completely unclear to me how this
>follows from John's feedback, at the least). Neither is there a
>requirement, implied or otherwise, for features to be useful to 'everyone
>on the planet'. It's also pretty hard for me to understand how a behavior
>can be both optional for UAs yet required for Unicode-compliance.
>
>Anyway.
>
>We need to stop this increasingly argumentative debate about compliance,
>the relative authority thereof and other assumed implementation costs.
>It's completely unhelpful and unproductive, as all clashes of general
>opinions tend to be.
>
>It's also 100% irrelevant to my specific request; you have repeatedly
>mentioned that *implementors* have asked for the spec prose John
>disagrees with; that's great but last time I checked John was also an
>implementor and a member of this WG. He has also explained why he
>disagreed. Can you please provide details on *why* those other
>implementors want what they asked for e.g. the content patterns where
>they expect this logic to be better than the alternatives? That seems the
>soundest basis to resolve this. If you can't explain why and/or if they
>cannot submit their feedback here then I am not confident it should be
>specified (unless maybe other experts in the WG can back it up with their
>own reasoning and hard data).
>
>You clearly believe the feedback from those implementors to be more
>valid/important than John's; and that's fine. But you must explain why
>your preferred proposal is better for authors and implementors alike in
>concrete feature terms. Appealing to the higher authority of the Unicode
>process as you perceive it is simply not relevant here. We do not and
>should not specify features to work a certain way just because the editor
>believes Unicode said so. (Or any other standard body, for that matter).
>
>Last, I do not wish to read or write as many words devoid of concrete
>technical arguments again in this thread. If you wish to discuss UTC
>voting process, please start a separate thread on the relevant mailing
>list (wherever that may be). Thanks.
>
>
>>
>>-----Original Message-----
>>From: Sylvain Galineau [mailto:galineau@adobe.com]
>>Sent: Friday, September 27, 2013 8:58 AM
>>To: Koji Ishii
>>Cc: W3C Style
>>Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr'
>>codepoints in 'text-orientation'
>>
>>
>>
>>On 9/26/13 8:52 AM, "Koji Ishii" <kojiishi@gluesoft.co.jp> wrote:
>>>
>>>I do not see any values to prohibit Unicode-compliant implementations
>>>and ignore people who wants it, especially when some people
>>>specifically asked for it, just because other people does not think
>>>the work isn't worth to do. Whether it's worth or not varies by people
>>>and situations around him/her.
>>
>>FWIW I do not think the issue is whether someone asked for it; I think
>>the question was *why* they asked for it. Can you ask them or point
>>them to this mailing list? That'd be useful feedback, I think;
>>implementor requests are not all inherently reasonable and it's quite
>>possible they're wrong, in which case we could all save ourselves some
>>work.
>>Alternatively their request is based on sound data the production of
>>which could help us resolve this issue and clarify the spec accordingly.
>>
>>Bottom line: given two contradictory pieces of feedback, it'd help the
>>WG if you provided all the data it needs.
>>
>>As a matter of principle I also strongly agree that optional behavior
>>is something we should avoid specifying in CSS or the web platform.
>>
>

Received on Sunday, 29 September 2013 16:11:13 UTC