- From: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
- Date: Fri, 4 Oct 2013 21:59:39 +0000
- To: Koji Ishii <kojiishi@gluesoft.co.jp>, "www-style@w3.org" <www-style@w3.org>, "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
> -----Original Message----- > From: Koji Ishii [mailto:kojiishi@gluesoft.co.jp] > Sent: Saturday, September 28, 2013 4:30 AM > > John is making 3 different arguments in parallel: > 1. Tr in UTR#50 has technical issues. This should go to Unicode, not www- > style. > 2. Tr impl costs is not worth to its value. Accepted. CSS now allows tailoring by > re-defining Tr as U. The diff by this change is subtle. > 3. CSS should prohibit impl of Tr as defined in UTR#50 for consistency and > simplicity. Disagreed, 1) we should allow any Unicode-compliant impl as CSS- > compliant, 2) we acknowledged the diff is subtle in #2, and 3) UTR#50 impl is > simpler under different architecture. > > Some members of UTC requested that CSS should allow any Unicode- > compliant impl as CSS-compliant. > > Sylvain said as a matter of principle we should avoid optional behavior. > I also support this statement. Every time we leave something optional we end up introducing inconsistency of behavior which ultimately results in bad user experience. So, let's try to avoid it here please. > James Clark said, for the same reason as John's #3 and Sylvain, CSS should > only allow UTR#50-compliant impl and disallow tailoring. > > My preference is to allow both UTR#50 and the tailoring in John's #2. CSS > already allows a lot of tailoring, such as Turkish uppercasing or UAX#14 > grapheme cluster. As a secondary preference, if tailoring is really bad and > that subtle consistency is critical, I'd agree with James. > How about take it out of CSS all together? Unicode already defines it all so why can't we leave it at that and remove these properties from CSS? Rossen
Received on Friday, 4 October 2013 22:00:11 UTC