W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2011

Re: [css3-ruby][css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

From: Alan Gresley <alan@css-class.com>
Date: Sat, 08 Jan 2011 03:22:29 +1100
Message-ID: <4D273DC5.1080106@css-class.com>
To: Koji Ishii <kojiishi@gluesoft.co.jp>
CC: David Hyatt <hyatt@apple.com>, "www-style@w3.org list" <www-style@w3.org>, "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
On 4/01/2011 3:57 PM, Koji Ishii wrote:
> It took time, but I think we have a good consensus in W3C Japanese ML
> and in JLTF meeting.
>
> Basically, ruby text should not affect layout at all. To be more
> exact: * It should not be included in the line box. If it does, it
> won't be layout properly when vertical-align is not baseline. * It
> should be rendered even when it goes beyond the containing block.
>
> The UA should test if the ruby text box interludes the AD box of the
> previous line within the block formatting context, including the case
> where the previous line is in a different block, and if it does, the
> UA should offset the line to avoid overlaps. If the previous line has
> another ruby text on the "after" side, the bottom of the ruby text
> box should be used instead. Also if any elements between the element
> and the element of the previous line has visible borders between the
> two, it may be used to detect overlaps instead.
>
> If there is no previous line in the block formatting context; i.e.,
> if the line is top of the block formatting context, the test should
> be skipped.
>
> If the ruby text is ''after'' side; e.g., vertical-lr or
> ruby-position:under, the ruby text box should be tested against the
> AD box of the next line in the block formatting context, and if it
> interludes, the next line should offset instead.
>
> The UA may use an alternate method for the test if it prefers. In
> this method, the vertical center of the ruby text box is compared
> against the top of the line box (the top of half-leading) as in the
> picture [1]. Assuming the previous line has at least the same
> half-leading, this test can be equivalent to the method above. There
> are cases where the assumption breaks, like when the previous element
> is a replaced element, but most of the time the author would use
> paddings and margins for such cases.
>
> Well, I guess I have to brush this up a little further both in
> technical and in English to make it a spec, but I hope this is
> understandable for anyone who is interested in this topic for now.
>
> Any opinions and feedbacks are greatly appreciated.
>
> [1]
> http://lists.w3.org/Archives/Public/www-archive/2010Dec/att-0006/ruby-overlap.png
>
>
>
> Regards, Koji


I really not to sure this is wise. Looking at the image that you have 
linked, it seems you are redefining the line box or inline formatting. 
To break ruby out of an line box and even out of a containing block can 
possibly impact on how inline formatting and block formatting currently 
work together. It's behavior is somewhat like text-shadow or box-shadow 
with a shadow directly above (or before), both of which don't effect the 
layout.

Testing in IE8 mode (IE9 beta), IE9 beta and Safari, I see that ruby 
annotations already have a default formatting. Is this not suiting what 
is required?


<http://css-class.com/test/css/text/ruby.htm>

<http://css-class.com/test/css/text/ruby-vertical.htm>


What I do note in IE8 mode (IE9 beta), IE9 beta and Safari is that when 
line-height is below it default size (around 1.2 or 120%) unlike in non 
ruby text (Latin), the height of the line never goes below this default 
size. It's like a clamping to accommodate ruby.

The test in IE9 beta for vertical shows that this clamping is broken. I 
not sure if this is due to height not being used (line-width ???).

Lastly some questions.

1. What vertical-align position are you talking about that is not baseline?

2. What does AD mean?


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Friday, 7 January 2011 16:24:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 January 2011 16:24:08 GMT