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

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.

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.

Is there actually a requirement for group ruby that splits on line wrap? 
I don't remember one – only that jukugo ruby does that. But 
ruby-merge:collapse and ruby-merge:auto (which is supposedly there for 
jukugo) are different settings.

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.

Note, btw, that this property is not supported by any major browser at 
the moment (unlike the other properties).

ri

Received on Thursday, 24 September 2015 16:51:46 UTC