- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Mon, 3 Jan 2011 23:57:21 -0500
- To: David Hyatt <hyatt@apple.com>
- CC: "www-style@w3.org list" <www-style@w3.org>, "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
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 -----Original Message----- From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Koji Ishii Sent: Saturday, December 11, 2010 4:55 AM To: David Hyatt Cc: www-style@w3.org list; CJK discussion (public-i18n-cjk@w3.org) Subject: RE: [css3-ruby][css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property Please forget the "150%" idea; we've got a better one. I made a picture to make sure we're on the same page. http://lists.w3.org/Archives/Public/www-archive/2010Dec/att-0006/ruby-overlap.png The gray boxes are line boxes. The two line boxes can be either within blocks or cross blocks. The sample picture does not include paddings/borders/margins. GOALS: If a line has at least one "rubyB", use "include-ruby"; the 2nd line in the picture is moved down. Otherwise use "exclude-ruby"; i.e., the ruby is ignored for line stacking. OPTION 1: Compare the top of the ruby box against the (bottom of line box - half-leading) of the previous line. OPTION 2: Calculate the vertical center of the ruby box (red horizontal line in the picture), then compare it against the top of the line box. PROS/CONS for OPTION 1: * Figuring out "the previous line" could be difficult. If we define it as "the previous line in the block formatting context", floats are always "exclude-ruby", and thus it may overlap the previous line. If we define it as "the previous line within the HTML stream", blocks after floats may overlap blocks before floats. Also, page-break must be treated special. * The logic/code can be complex, as it needs to find the previous/next line. PROS/CONS for OPTION 2: * The ruby may overlap if the previous line has smaller leading. This includes smaller font-size, smaller line-height, and replaced elements. ADDITIONAL OPTION: If the element has visible borders, compare the top of the ruby box against it. If the ruby box overlaps the border, use "include-ruby". DISCUSSIONS IN JAPAN: I discussed this in the meeting of about 10 people including JLTF members, and also got some responses in two Japanese MLs. Everyone from there thinks either is a good option, and edge cases are good compromises. Some prefers OPTION 2 because it looks simpler, but nobody has good idea how much actually it is from coding point of view, so we concluded that we'd ask opinions here by showing both options. Some said that the spec could make the actual condition UA dependent, and show these options as examples if it helps implementers. The ADDITIONAL OPTION is nice to have. It helps "auto" value works within table cells and when the block has borders. But experts think authors would add paddings in most of the cases, so it is not required to have it. ACTUAL SIZE V.S. FONT SIZE ISSUE: There was an argument where font-size should be used instead of actual box size to avoid using "include-ruby" unexpectedly as a result of non-linear scaling of fonts, and/or possible fractions of glyphs. We were not sure how much it really is a problem, so the argument was that using font-size is safer. Maybe this can be UA dependent. I hope this mail clarifies current situation. Please feel free to ask me any questions, and any feedbacks are greatly appreciated. Regards, Koji
Received on Tuesday, 4 January 2011 04:55:27 UTC