W3C home > Mailing lists > Public > public-html-admin@w3.org > February 2013

[Bug 21040] New: Double-sided ruby

From: <bugzilla@jessica.w3.org>
Date: Mon, 18 Feb 2013 14:57:03 +0000
To: public-html-admin@w3.org
Message-ID: <bug-21040-2495@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21040

            Bug ID: 21040
           Summary: Double-sided ruby
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#the
                    -ruby-element
                OS: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec
          Assignee: robin@w3.org
          Reporter: robin@w3.org
        QA Contact: public-html-bugzilla@w3.org
                CC: eoconnor@apple.com, ian@hixie.ch,
                    jackalmage@gmail.com, kojiishi@gluesoft.co.jp,
                    mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org
        Depends on: 20115

+++ This bug was initially created as a clone of Bug #20115 +++

From:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0370.html


When you want to create double-sided ruby, with the ruby text on both
sides of base text, the current HTML model posits two separate and
fairly different markup models.

In the first, when the group boundaries for both ruby text runs are
the same, it allows you to have two <rt>s following an <rb>, with the
obvious meaning.

In the second, when the group boundaries do *not* line up (in
particular, for the common case where one line of ruby is
per-character and the other is for the whole group, such as with a
pinyin and English translation), it requires you to nest two <ruby>
elements, with the inner one supplying the per-character annotations
and the outer supplying the whole-group ones.

Having to learn and use two different markup patterns for two nearly
identical use-cases is sub-optimal for authors.  It would be best if
they could just learn one model that works for both.

On the implementation side, this also requires two different layout
models for essentially the exact same thing.  This is unnecessarily
complicated; again, one simple way to get both would be preferred.

This is easy to address.  Add an <rtc> element (name taken from the
XHTML Ruby module), which is used for the second line of text.  You
can fill an <rtc> with <rt> elements, in which case they match up
index-wise with the preceding run of <rb> elements.  The last <rt>
(or, if no <rt>s were given at all, the naked text that was implicitly
wrapped in an <rt>) automatically spans the remaining bases in the
preceding run.

This makes both cases trivial.  If both runs of ruby are
per-character, you can just write:

<ruby><rb>FOO<rb>BAR<rt>baz1<rt>baz2<rtc><rt>qux1<rt>qux2</ruby>

Or, in the pure column-based model:

<ruby>FOO<rt>baz1<rtc>qux1<rb>BAR<rt>baz2<rtc>qux2</ruby>

Alternately, if the second line of ruby text spans the entire group,
that's also trivial, and very simlar:

<ruby><rb>FOO<rb>BAR<rt>baz1<rt>baz2<rtc>qux1 qux2</ruby>

As you can see, the only difference is that the <rtc> contains a
single (implicit) <rt>, rather than two <rt>s.  It seems plainly
obviously that this is simpler for authors; it's also simpler for
implementors, because we don't have to infer that we should be
formatting something as double-ruby from the presence of nested <ruby>
elements.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 18 February 2013 14:57:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 February 2013 14:57:10 GMT