W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2013

Re: Ruby: questions about fallback

From: Robin Berjon <robin@w3.org>
Date: Thu, 07 Mar 2013 16:48:09 +0100
Message-ID: <5138B6B9.5000706@w3.org>
To: Richard Ishida <ishida@w3.org>
CC: "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>, "KOBAYASHI Tatsuo(FAMILY Given)" <tlk@kobysh.com>, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
On 06/03/2013 11:43 , Richard Ishida wrote:
> [3] API ruby support detector
>
> The problem with fallback is that you can't provide characters such as
> parentheses to clarify the repetition of base and ruby text for the
> reader unless you provide rp elements around all your ruby text. It is a
> tall order to expect that everyone will do that religiously. Not only
> does it significantly increase the amount of effort required to create
> ruby markup, but it makes the source text more difficult to read, and
> adds complexity when it comes to searching text.
>
> For inline ruby text, styling can provide the needed delimiters, using
> :before and :after, but this approach can't be used for general fallback
> because such an approach would also produce delimiters around ruby text
> if the browser is capable of displaying ruby text above or below the
> base text.
>
> A possible solution might be to test whether the browser supports ruby
> using scripting. For this to work, it would be necessary for the DOM API
> to indicate whether ruby is supported by the browser. Browers would set
> this to true when they add ruby support.

There are three ways that we can go about this, one of which is bad.

The bad one is using some form of rubySupported boolean or version field 
in the DOM. Browsers have a long and proud history of completely 
screwing up the way in which they expose features that they support or 
not. The first browser to ship with a broken flag (in either direction) 
basically poisons the water for the whole herd, making this a weak approach.

The hacker's way, or how I'd do this in Modernizr for instance, would be 
to do something like create a ruby element containing just a base, set 
some predictable CSS on it, measure its bounding box, then add an 
annotation and measure the box again to see if it has grown in the 
expected direction. This probably works today already.

Finally, another way of doing this would be to surface the ruby 
information to the DOM (e.g list of bases, base ranges, annotations, 
etc.). That would help a lot with feature detection, but it's not 
something that I would recommend if the only use case is feature detect.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 7 March 2013 15:48:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 March 2013 15:48:23 GMT