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

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


-----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 13:26:18 UTC