- From: Florian Rivoal <florianr@opera.com>
- Date: Fri, 07 Oct 2011 16:20:24 +0900
- To: www-style@w3.org
On Wed, 05 Oct 2011 02:11:50 +0900, Koji Ishii <kojiishi@gluesoft.co.jp> wrote: > Assuming you guys know that the use case for the value is Ruby; I don't > think people who wants to use ruby on the web is "very few". > > The next question is how many percent of ruby usage would use this > feature. I don't have the data, but if we learn from publishing, most > published materials apply this rule to Ruby today. So, I think "very > few" is too strong. The basic idea of the feature is small Kana in Ruby > are too hard to read. It's even harder to read small letters on screen > than when printed. It all depends on the perspective, but I would say the need for full-size-kana is indeed quite limited. First it is specific to the Japanese language. Within Japanese, it is limited to documents using ruby. Then, it is a stylistic choice: some authors will actually prefer the small size kana. It doesn't mean there is no real use case, but it is a specialized one. It is the most prominent specialized use case we currently have. I think it would be a good opportunity to use it to drive a generic solutions that can benefit others. > Regarding the "full-size-kana" or general @-rules; I'm more than happy > to agree with @-rules if there were several use cases just like CSS3 > Lists @counter-style does. I actually like the idea very much, and I > heard some people like it too. But as far as I know, "full-size-kana" is > the only use case for now. As long as there's only one use case, I think > developing @-rules is too much feature. > > If we find more use cases in future, we could migrate "full-size-kana" > to @-rules as CSS3 Lists did from CSS2. A few other specialized used cases have been mentioned. Of course, they are all relatively minor, but that's the point: since they are unlikely to be addressed individually, trying to aim for a generic solution that solves all in one go sounds better to me. A few examples, either already mentioned or reasonable to expect: * Removing accents. This cannot be solved properly in the generic case, so the WG has (rightfully) rejected a hard-coded text transform to do that. But in more limited contexts, it would often be perfectly doable for authors to define a custom rule that removes accents the way they want it. * Hakon has mentioned mkhedruli to asomtavruli http://en.wikipedia.org/wiki/Letter_case#Other_forms_of_case * hiragana to katakana: the mapping is easy to determine, and this could be desirable once in a while for stylistic reasons * mapping U-2014 to U-2015 (or the other way around), as mentioned in the writing modes discussion. * ſ (long s) to s Regards, - Florian
Received on Friday, 7 October 2011 07:21:10 UTC