ISSUE-359: Drop ruby-merge in favour of a specific jukugo value

Drop ruby-merge in favour of a specific jukugo value

State:
CLOSED
Product:
css-ruby
Raised by:
Richard Ishida
Opened on:
2014-07-04
Description:
http://www.w3.org/Mail/flatten/index?subject=i18n-ISSUE-359&list=www-style


================

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).
Related Actions Items:
No related actions
Related emails:
  1. Re: Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from ishida@w3.org on 2015-10-02)
  2. Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from jackalmage@gmail.com on 2015-10-01)
  3. Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from fantasai.lists@inkedblade.net on 2015-10-01)
  4. Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from kojiishi@gmail.com on 2015-10-01)
  5. Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from jackalmage@gmail.com on 2015-09-30)
  6. Re: i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from fantasai.lists@inkedblade.net on 2015-09-29)
  7. i18n-ISSUE-359: [css-ruby] Drop ruby-merge in favour of a specific jukugo value (from ishida@w3.org on 2015-09-24)
  8. I18N-ACTION-471: Forward issue-359 to css (from sysbot+tracker@w3.org on 2015-09-24)
  9. I18N-ISSUE-359: Drop ruby-merge in favour of a specific jukugo value [css-ruby] (from sysbot+tracker@w3.org on 2014-07-04)

Related notes:

https://github.com/w3c/i18n-activity/issues/98

Richard Ishida, 17 Mar 2016, 12:30:44

Display change log ATOM feed


Addison Phillips <addison@amazon.com>, Chair, Richard Ishida <ishida@w3.org>, Fuqiao Xue <xfq@w3.org>, Atsushi Shimono <atsushi@w3.org>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.326 2018/10/13 17:29:51 vivien Exp $