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

Fwd: HTML Ruby extensions

From: Richard Ishida <ishida@w3.org>
Date: Mon, 07 Oct 2013 21:02:32 +0100
Message-ID: <52531358.9020700@w3.org>
To: www International <www-international@w3.org>, "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>

-------- Original Message --------
Subject: HTML Ruby extensions
Resent-Date: Mon, 07 Oct 2013 19:02:43 +0000
Resent-From: public-html@w3.org
Date: Mon, 07 Oct 2013 21:02:32 +0200
From: Robin Berjon <robin@w3.org>
To: HTML WG (public-html@w3.org) <public-html@w3.org>

Dear all,

I am about to send an email to public-html-admin requesting publication
for an extension specification covering HTML Ruby, but that's just the
administrativia and I wanted to prod this crowd here for feedback.

The draft snapshot is at:


The editor's draft:


The extension spec addresses the following bugs:


In general, it addresses the use cases carefully gathered and developed
over time by our friends in the I18N group:


More specifically, it changes the current HTML specification in the
following ways:

     • Removes nested <ruby> elements as a way of capturing double-sided
ruby. As far as I can tell this is not implemented and not a single
instance shows up in the corpora I've been able to access. An <rtc>
element is introduced instead, which has a cleaner and more extensible model
     • Introduces an <rb> element for explicit ruby base text. This
corresponds to actual usage in the wild where the <rb> element is
relatively common. It also makes some use cases simpler to address.
     • The algorithm to process ruby has been entirely overhauled. The
existing one is buggy, and does not process white space in a
satisfactory manner for non-CJK languages.

Overall, since alignment with CSS is particularly important in this
case, I also worked closely with Fantasai in order to align well with
the new CSS Ruby model:


The goal for this extension specification is to be reviewed on its own,
but to eventually become integrated into the HTML specification. How
much of it gets integrated and when largely depends on implementations.
If implementations support this inside of the CR period, then all of it
will simply be folded into HTML. If however the newer features are not
yet supported well enough, a "viable subset" will get folded in. That
viable subset will be primarily comprised of existing elements as
processed by the new algorithm.

As a final note, those of you who are interested in such things may be
interested to see that I am requesting publication of this document
under the new dual CC-BY/W3C license. But more about that in my coming
email to the -admin list.

Your feedback is very much welcome!

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 7 October 2013 20:03:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:59:19 UTC