W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css3-text] comments on text-transform

From: Florian Rivoal <florianr@opera.com>
Date: Fri, 07 Oct 2011 16:20:24 +0900
To: www-style@w3.org
Message-ID: <op.v2yz0ah14p7avi@localhost.localdomain>
On Wed, 05 Oct 2011 02:11:50 +0900, Koji Ishii <kojiishi@gluesoft.co.jp>  

> 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  
is indeed quite limited. First it is specific to the Japanese language.  
Japanese, it is limited to documents using ruby. Then, it is a stylistic  
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  

* 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


  - Florian
Received on Friday, 7 October 2011 07:21:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:05 UTC