W3C home > Mailing lists > Public > www-style@w3.org > December 2010

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

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Wed, 1 Dec 2010 22:49:44 -0500
To: David Hyatt <hyatt@apple.com>
CC: "www-style@w3.org list" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AA8B1B6BA@MAILR001.mail.lan>
As I re-read what I wrote, I figured that I wasn't writing as good to include all writing modes cases as Dave did, so re-writing here. I hope this text covers both vertical-rl case and ruby-position property.

---
Line stacking is the same as ''exclude-ruby'', except when the ruby text overlaps the previous or next line of the side where ruby text is on within the same block. In that case, the line that contains the ruby text should be moved to the after direction. If the ruby text is on after side of the line, the next line is moved instead.

If the line that contains ruby text is at the top of a document, column, or page, the previous line should be considered as if it does not exist, and therefore ''exclude-ruby'' is applied.
---

I believe ruby text being allowed to extend into the padding area should be considered as part of ''exclude-ruby'' behavior anyway, so I didn't include in the above text. Please correct me if I'm wrong here.


Regards,
Koji

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Koji Ishii
Sent: Thursday, December 02, 2010 12:31 PM
To: David Hyatt
Cc: www-style@w3.org list
Subject: RE: [css3-ruby][css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

Thank you for your kind and detailed explanations. I was wondering how it'd work on cross blocks case, now I understand that, and if it's complicated, I'm happy to line without it.

In order to fully support line stacking for a professional typography in Japanese, my opinion is that we will need line grid spec, and I'm looking forward to working on the spec in future. But since the spec is far from complete, our goal for now should be to figure out what the reasonable level is for both browser developers and publishers. Not supporting cross blocks looks reasonable to me.

Thanks to your support, the "auto" behavior should be something like this:

---
Line stacking is the same as ''exclude-ruby'', except when the ruby text overlaps the previous line (the line in the before direction) within the same block. In that case, the line that contains the ruby text should be moved to the after direction.

If the line that contains ruby text is at the top of a document, column, or page, the previous line should be considered as if it does not exist, and therefore ''exclude-ruby'' is applied.
---

I'm not sure how much details is needed for how "overlaps the previous line" is defined in the spec. If there're feedbacks we'd need more, your explanation must be a great help.

Thank you for your support to make this proposal better, Dave.

If anyone else have any opinions or feedbacks, it'd be also greatly appreciated.


Regards,
Koji

-----Original Message-----
From: David Hyatt [mailto:hyatt@apple.com] 
Sent: Thursday, December 02, 2010 7:12 AM
To: Koji Ishii
Cc: www-style@w3.org list
Subject: Re: [css3-ruby][css3-linebox] Proposal to add "auto" value for the line-stacking-ruby property

On Dec 1, 2010, at 10:24 AM, Koji Ishii wrote:

> Dave,
> 
> Would you mind if I ask a question? It may be odd for me to ask this, but how accurate can a browser detect when "ruby overlaps the previous line"?
> 
> Given the case of the first line after page break, I started to think if there were any other such cases. Is it possible to share with us what you have in WebKit now?
> 

In WebKit, lines have a concept of a lineTop and a lineBottom.  The lineTop and lineBottom represent the highest and lowest border edges of any inline boxes on the line (excluding line-height and overflow).  The overlap code checks to see if the Ruby intrudes into the previous line's vertical range (above lineBottom of the previous line).  If the Ruby does intrude, then the line with the Ruby is moved down just enough so that the top edge of the Ruby lines up with the lineBottom of the previous line.  In addition, for first lines, the Ruby is allowed to extend into the padding area at the before side of the block.  So think of the "previous line's lineBottom" in that case as being the border edge.

For vertical-lr this is flipped.  Ruby is checking to see if it intrudes into the next line, and the next line gets moved.  Rubies on the last line can extend into the padding area at the after side of the block.

> Cases I thought are:
> * Floating box moves to either left or right, so it can still detect where the previous line is.
> * Text after floating box probably knows where the line before the floating box is.

Floating doesn't confuse the above algorithm, since if you introduce big vertical spaces between lines, that space will be in between the lineBottom of the previous line and the lineTop of the line with the Ruby on it.

> * If the element has top or bottom (left or right in vertical) property specified, it's probably hard to determine what the "previous" line is.
> 

I don't really understand what you mean here.  Are you talking about positioning?

> As far as I thought for a while, the top/bottom case and the first line after page break (and column break if multicol) you mentioned are the only two cases where browser cannot know where the previous line is.
> 

If the algorithm has to cross blocks to detect overlap it gets significantly more complicated.  WebKit doesn't attempt to cross blocks right now, so it doesn't detect that a Ruby can fit in a margin area between two blocks (or at the top of the document or the top of a column/page).  If we did want to support this behavior automatically, I'd be inclined to only do it when at the top of a document, column or page, since that is much easier to handle than the between-blocks case.

dave
(hyatt@apple.com)
Received on Thursday, 2 December 2010 03:52:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT