- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Nov 2011 19:30:24 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13113 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard|needs data | Severity|normal |enhancement --- Comment #17 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-11-02 19:30:21 UTC --- I spoke with the i18n group about this yesterday, and it seems that we don't really need to add any elements to handle the important use cases here. Multiple annotations can be handled pretty easily if we just define that nested ruby is semantically equivalent to two annotations; picking which side the annotations appear on is a stylistic issue for CSS. Monoruby and group ruby are both handled already; the only difference is the how much is put in the ruby base before the annotation. Jukugo is a stylistic variant of group ruby, again to be handled in CSS. Fallback if we rely on this simple pattern is suboptimal, but that doesn't seem to be a big deal. It's time for implementations to just implement ruby. AT fallback is not impossible in any of these cases and is unaffected by how we mark it up. The last remaining case is what to do with multiple annotation if there is word-pairing for each component. Not supporting this doesn't seem like a big deal, but if we do want to support it, we could do it with multiple <rt>s for each ruby base. In conclusion, the spec should be changed to limit ruby nesting to two levels, defining the outer level as a phrase-level annotation; and we should consider supporting multiple <rt>s per base, if there is reason to believe that multiple monoruby annotations at the ends of lines are common. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 2 November 2011 19:30:30 UTC