W3C home > Mailing lists > Public > www-international@w3.org > October to December 2015

Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 30 Sep 2015 17:06:39 -0700
Message-ID: <CAAWBYDB+569StuvcL6brducRsbt-47Nve2ndxzOr+eiGHK3dZA@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Richard Ishida <ishida@w3.org>, W3C Style <www-style@w3.org>, www International <www-international@w3.org>
On Tue, Sep 29, 2015 at 6:02 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 09/24/2015 12:51 PM, Richard Ishida wrote:
>> http://www.w3.org/TR/css-ruby-1/#collapsed-ruby
>> 4.2 Sharing Annotation Space: the ruby-merge property
>> I think the new ruby-merge property in the editor's draft is
>> overthinking the task. If people want to identify group ruby as
>> such let them mark it up appropriately, at least for Level 1.
> "Group ruby" is not the same -- it a term used for a ruby annotation
> which has multi-character base text, and there is no smaller mapping.
> E.g. mapping “San Francisco” to 旧金山 or “あした” to 明日. There is
> no smaller unit of correspondence that can be marked up, so the base
> text must "as a group" be placed into the base text box.
> Note: A lot of thinking and terminology around ruby is based on
> a per-character model of thinking, but HTML and CSS are based on
> a per-box model of thinking, where the boxes can have one or more
> characters as their contents.

Yeah, "mono" and "group" ruby are both covered under "ruby-merge:
separate", meaning "each base lays out with its individual ruby text".

>> I suspect this is an generalisation from an desire to support
>> jukugo ruby. But i think ruby-merge actually spoils things for
>> jukugo the way it's currently set up. Jukugo implies a specific
>> set of rules that i think people will want to apply explicitly
>> rather than possibly getting or possibly not getting what they
>> want via auto.
> I think it's fine to get rid of the 'auto' value if that seems to
> make sense.
>> Is there actually a requirement for group ruby that splits on
>> line wrap?
> I'm not sure about the line wrapping aspect, but I can imagine
> ruby-merge being used when the ruby consists of romanized phonetics:
> in that case, the markup should map each base character to its
> pronunciation, since that is the fundamental structural correspondence.
> But there's a stylistic choice between whether the ruby should be
> presented as mono ruby with the phonetics centered per character,
> or as word-based ruby where the phonetics are centered per word.

That seems to be well-handled by marking up each word as a separate
<ruby>, with 'ruby-merge' dictating whether the phonetics are
per-character or merged into a continuous word.

>> So, I'm not convinced that we really need ruby-merge for level 1,
>> and I think that we should have a simple property for turning on
>> jukugo.
> I don't mind deferring ruby-merge to level 2, or adding a value
> that enables specifically the JLREQ algorithm or JISX4051 algorithm.
> However I don't think we should have a separate property for jukugo
> compared to other annotation-merging effects.
> Given the draft is still in an early stage (not very stable, needs
> a lot of work), I'd prefer speccing the appropriate switch for
> jukugo, and dropping it only if there's still no implementation
> interest once we get closer to CR.

Based on an admittedly quick re-read of the spec, can we just make
"ruby-merge: collapse;" be the jukugo value?  With an explicit
reference to JLREQ to specify it.  I'm not sure I see the value in
specifying a third alternative to mono/jukugo, if those are the only
two real ruby layout modes in practice.  It sounds like the jukugo
algorithm is just a well-specified attractive form of

Received on Thursday, 1 October 2015 00:07:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:09 UTC