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 Friday, 27 September 2013 15:58:56 UTC