- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Nov 2011 19:30:25 +0000
- To: public-i18n-cjk@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 on the CC list for the bug.
Received on Wednesday, 2 November 2011 19:30:28 UTC