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

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

http://www.w3.org/International/track/issues/359

Raised by: Richard Ishida
On product: css-ruby

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. I suspect this is an generalisation from an desire to support jukugo ruby. Apart from the point that jukugo is probably an advanced feature that can be tackled after the basics are provided for, 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. 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.

In private email, Fantasai said:
"The default is going to be mono ruby. If people want a switch
for jukugo, that's what ruby-merge is for. If we want to have
a value that is only for the particular jukugo algorithm in
JLREQ and if you can't do exactly that you don't do anything
with this property, then we can do that. Please send a comment
to that effect."

I am proposing that we remove the ruby-merge property and that, when we are ready to spec support for jukugo ruby, we add a value for the particular jukugo algorithm in JLREQ, and if the browser can't do that it falls back to mono-ruby.

Received on Friday, 4 July 2014 11:53:29 UTC