W3C home > Mailing lists > Public > www-style@w3.org > July 2014

[css-ruby][html-ruby] Bidi handling of ruby now defined

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 12 Jul 2014 01:45:15 -0700
Message-ID: <53C0F59B.60807@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>, "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>, whatwg@lists.whatwg.org, "public-html@w3.org" <public-html@w3.org>
I just checked in a new section on the handling of bidirectional
reordering in CSS Ruby, which you can see in the editor's draft here:
   http://dev.w3.org/csswg/css-ruby/#bidi

The layout-imposed constraints I had to work with are:
   * the contents of a ruby base or ruby annotation need to be contiguous
   * ruby annotations need to stay with their bases
   * all bases spanned by a single annotation must be contiguous
(This is all fairly obvious once you think about it.)

The simplest way to ensure all of this was to
   * Force bidi-isolation on all ruby elements. This ensures they are contiguous.
     (Bidi reordering can normally break apart text.)
   * Order the ruby bases and annotations strictly by their container's 'direction'.

What this means for authors is:
   * Implicit reordering doesn't work across ruby bases/annotations
     (but does within a single ruby base or annotation).
   * If your <ruby> element's declared or inherited directionality
     doesn't match its contents, you're gonna have a bad time.

Comments welcome.

                               *      *      *

Also, because layout needs to impose bidi isolation on ruby content,
I'm suggesting that the HTML specs include a default UA style rule of
   unicode-bidi: isolate;
for all of the ruby elements. This will give slightly more consistent bidi
results in cases where those elements are not laid out as ruby. (Bidi will
still be able to shuffle around implicit bases in weird ways, but it's the
best we can do.)

However, there is one downside to this: if the <ruby> has a <bdo> ancestor,
the override will not work within the <ruby> unless the author overrides
that rule.

Comments welcome on this issue as well.

~fantasai
Received on Saturday, 12 July 2014 08:45:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC