W3C home > Mailing lists > Public > www-international@w3.org > July to September 2022

Re: For review: Ruby Styling

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 12 Jul 2022 15:52:14 +0200
Message-Id: <A04C328F-9017-4EE3-BC33-3FF0AD7287FA@rivoal.net>
Cc: www-international@w3.org
To: r12a <ishida@w3.org>
Hi,

Here are a few comments, mostly in the order I thought about them:

1) In the "Basic configurations” / “Japanese” section

> Mono ruby <http://w3c.github.io/i18n-drafts/articles/ruby/markup.en.html#mono_group_etc> is typically used to represent pronunciation of Japanese kanji characters.

Mostly true, but mildly misleading: in words made of a single character, mono-ruby is typical (since that’s the only thing you can do anyway).

In compound words (Jukugo), the mono-ruby style of rendering may be used (I’d say mainly on young readers’ material), but it is not typical. Jukugo-ruby would be more typical.

The example given is one where the jukugo-style would be more common, further reinforcing this possible misconception. Maybe rephrase as:

> Mono ruby <http://w3c.github.io/i18n-drafts/articles/ruby/markup.en.html#mono_group_etc> is used to represent pronunciation of Japanese kanji characters, typically for words made of a single character, and occasionally also for compound words.


2) In the "Aligning to one edge” section

* As the text says, this is typically used for vertical Japanese, yet the example given is a horizontal one. I’d suggest switching to a vertical one
* I believe that when used in vertical text “kata-tsuki ruby” is somewhat more complex/smarter than simply aligning to the start edge, especially in cases of overflow and interaction with line edges. In the absence that sophistication I am unsure that anyone would chose this style. Since we don’t have the sophistication, I am not sure it is worth promoting this style, at least not without a warning that this may be simpler than what is expected of tradition printed material. Besides, it is somewhat old fashioned anyway.

3) in the “Handling gaps in annotations”

I’d suggest using the tabular markup rather than the interleaved one for the correct solution. Also, for the incorrect one (that omits the reduplicated り), the problematic parenthesized rendering should be
振(ふ)り仮(が)名(な) rather than 振り仮名(ふがな). Reordering content to place the parenthetical annotations grouped together after the bases, rather than interleaved, when the markup is itself interleave is far from a trivial problem.

4) in the "Rendering annotations inline”

> you'll need to use classes to indicate which set of CSS rules to apply to that particular ruby element.

This used to be true, the new :has() selector may make it possible to apply the right css to the right markup without manually adding classes.

—Florian

> On 8Jul 2022, at 16:50, r12a <ishida@w3.org> wrote:
> 
> The article Ruby Styling <https://w3c.github.io/i18n-drafts/articles/ruby/styling.en.html> is out for wide review. We are looking for comments by Thursday 14 July.
> 
> The article reviews the typical usage patterns of inline annotations for Japanese and Simplified/Traditional Chinese, and provides guidance for content authors about how to use features of the CSS Ruby spec to achieve the rendering they want. It also reports on current support for those features in the 3 major browser engines. This information should also be useful for authors writing in the Traditional Mongolian orthography.
> 
> This is a companion article to Ruby Markup <https://www.w3.org/International/articles/ruby/markup.en.html>, which focuses on how to mark up inline annotations.
> 
> Please send any comments as github issues by clicking on this link <https://github.com/w3c/i18n-drafts/issues/new?title=[articles/ruby/styling]%20%20BRIEF_TITLE_GOES_HERE&body=%5Bsource%5D%20%28https%3A%2F%2Fw3c.github.io%2Fi18n-drafts%2Farticles%2Fruby%2Fstyling.en.html%29%20%5Ben%5D%0A%0A>, or on “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)
> 
> 
> 
> 


Received on Tuesday, 12 July 2022 13:52:33 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 12 July 2022 13:52:33 UTC