- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Thu, 24 Oct 2013 06:32:26 -0400
- To: "www-style@w3.org" <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
- Message-ID: <CE8F264A.46102%kojiishi@gluesoft.co.jp>
Glenn and Daniel inspired me yet another, new approach to discuss this issue, so let me try to ask what you all think. We discussed a lot on which is better and why, but that's not really a discussion point, because one of the two groups has already acknowledged that the other group's method is fine. The real discussion point is that whether we want to normatively require single behavior, or allow optional behaviors. A. We should normatively require (MUST) one and only one way to implement Tr fallback Justifications as far as I remember are: 1. In general, less optional behavior is better. 2. Optional behavior costs more to developers. 3. Options will lead to inconsistency, which confuses authors. 4. The other option does not make sense to implement for who prefer one option. B. We should allow (MAY/SHOULD/Undefined) two or more ways to implement Tr fallback Justifications as far as I remember are: 1. One way costs more to one architecture, while the other costs more to another architecture, so choices will help developers. 2. Inconsistency is limited only to a handful code points so there won't be confusions for authors; up to 26 code points at maximum, and most of them do not appear because fonts cover most of them anyway. Also, it'll be completely gone if author uses UTR50-compatible, well-designed fonts. 3. At this point, it would be premature to mandate a single approach[1]. 4. Values and costs balance varies by markets/regions, so options are good. 5. If so controversial, we should not stop this important spec to go LC/CR just for this issue. If we reach consensus on A, we can discuss which is better. If we reach consensus on B, we don't have to discuss which is better. Feedback -- opinions, more justifications to either option, corrections to my misunderstanding, votes, etc. -- are greatly appreciated. [1] http://lists.w3.org/Archives/Public/www-style/2013Oct/0372.html /koji
Received on Thursday, 24 October 2013 10:33:04 UTC