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

Re: Memo from ruby disucssion with Roland

From: Roland Steiner <rolandsteiner@google.com>
Date: Wed, 22 Feb 2012 13:37:52 +0900
Message-ID: <CACFPSpjqFw4bqfSoPo-ad4XjpchuknR_bNkJkKUoVktJnO9LuQ@mail.gmail.com>
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: fantasai <fantasai.lists@inkedblade.net>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Sorry for chiming in late to this thread!

Koji summed up our discussion pretty well, I think. There's just one thing
I wanted to add to the reasoning of the 'for' approach for clarification:

With 'rspan' or <rtc>, there is no semantic link from the base to the
text(s). For example:

<ruby><rb>東<rb>京<rtc>とうきょう</ruby>


and similar with 'rspan' - in this case, even if you add, remove or edit
the bases dynamically, the ruby text will always be 'とうきょう'. This is what I
wanted to address with the 'for' attribute: the text would only be rendered
if the bases it refers are present within the same ruby, and rendered in
the order it refers them. E.g.

<ruby><rb id=T>東<rb id=K>京<rt for="T K">とうきょう</ruby>

In this case, 'とうきょう' should only be rendered if there are the bases 'T'
and 'K', consecutively, in that order. If, for example, the base for '東' is
removed, the text would no longer be applicable, and thus not rendered.
Neither would it be rendered if 'T' or 'K' are not the id of a <rb> within
the same ruby.
Now, I fully admit, that this is very verbose may not be all that
necessary. It also doesn't help if the innerText of the bases is changed.
Implementation is also tricky. OTOH, the advantage would be that a <rt>
does not have to neighbor a base.

The whole idea came from a discussion to alternatives to markup. That is,
for some use cases it would be nice to be able to generate ruby texts by
CSS rather than having to repeat markup. Along the lines of:

rb.東::ruby-text {
    content: "とう";
}


Cheers,

- Roland


On Mon, Feb 20, 2012 at 14:23, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:

> That's an interesting idea, I guess I missed that part when I read your
> blog last time.
>
> I like your idea to limit the spans to all or none. I agree the case you
> raised is very rare, so I don't think we need to support it. I would like
> it be expressed as rbspan="*" and don't allow arbitrary numbers for now,
> but your idea might be more acceptable for simplicity.
>
> What I learned from the discussion with Roland was, manipulating DOM and
> supporting edge cases are harder than creating box models from normal
> elements. From your proposal, I wonder:
> 1. What will happen if author writes <rtc>abc<rt>def</rt></rtc>
> 2. What will happen if author writes <rtc>abc</rtc>, and then insert <rt>
> as a child of <rtc>
>
> For id-approach, your response is understandable, Roland was aware of
> that. One of the cons of row-major approach is that, the parings of rt and
> rb are weak (just indexes) and therefore when rt or rb is inserted to DOM
> via JavaScript, UAs must shift all the parings of rb/rt boxes after the
> insertion point. That'd be a bit of code, and also it isn't easy for JS
> developers to correctly handle. His id-approach is one idea to avoid that,
> knowing it has other problems. I think he wants a bit more brainstorming if
> there were really no good idea to strength the pairing during the DOM
> manipulations. The best one so far was id-approach, which has other
> problems as you pointed out, so maybe we have to live with this, but I just
> want to keep in mind that this is a cons of row-major approach.
>
>
> Regards,
> Koji
>
> -----Original Message-----
> From: fantasai [mailto:fantasai.lists@inkedblade.net]
> Sent: Sunday, February 19, 2012 7:49 PM
> To: public-i18n-cjk@w3.org
> Subject: Re: Memo from ruby disucssion with Roland
>
> On 02/18/2012 02:28 PM, Koji Ishii wrote:
> > He didn't like rbspan because it makes box generation code complicated
> when elements are inserted/deleted dynamically.
>
> Hi Koji,
> I don't think there's a need for rbspan if you want to do this
>
>  group-note
> B1 B2 B3 B4
> T1 T2 T3 T4
>
> See http://fantasai.inkedblade.net/weblog/2011/ruby/ Level 3: Double Ruby
> - the idea is that text contained directly within an <rtc> is interpreted
> as spanning all bases.
>
> There's only need for rbspan if you want to do this
>
> span-1-3 T4
> B1 B2 B3 B4
> T1 span-2-4
>
> I haven't seen any examples of this, have you? I don't imagine it would be
> at all common...
>
> > Roland brought up yet another idea, using "for" attribute, like<label
> for="id">. The implementation may be more complicated than the two, but
> this approach can avoid using rbspan, which he didn't like.  For
> example,<rt for="B1 B2">  can avoid rbspan and tighten the relationship
> between base and ruby than rbspan does, although we need to define
> behaviors more precisely (e.g., what happens when B4 is inserted between B1
> and B2, etc.) I still haven't gave much thoughts on the idea yet, but it's
> probably worth to investigate further.
>
> This is awkward to author, and makes possible some very strange markup
> that makes no sense. Suppose someone puts in IDs for non-consecutive bases.
> Or bases from the previous line. Or the ID attribute of a <div>.
>
> (IMO, interfaces should be designed, insofar as practical, so that invalid
> or nonsensical input is simply not possible. This fails that test...)
>
> Thank you for the discussions and the summary!
>
> ~fantasai
>
>
>
Received on Wednesday, 22 February 2012 04:38:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 February 2012 04:38:43 GMT