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

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.

> 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.

> 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.

~fantasai

Received on Wednesday, 30 September 2015 01:03:20 UTC