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

After writing this up, a new idea came up in my mind, which is far much simpler.

* ''exclude-ruby'' if line-height is equal to or larger than 150%
* ''include-ruby'' otherwise

This idea covers all the three cases I raised below. However, this has not tested with typography experts yet. I'll talk to them very soon, but if anyone has any opinions in this ML, it'd be greatly appreciated.

Also a few notes for who's interested in this: first, I know I would need much more detailed wordings and edge cases to make this a spec; I'll dig into further if both typography experts and browser developers feel good about the basic idea.

Second. At 150%, the ruby box will probably go out of the line-height. I'm counting on ruby box being out of line-height is not technically difficult, but it may depend on current browser implementation. Any feedbacks on this would be appreciated.

The last. I'm aware of some edge cases exist where ruby and other lines intrude each other with this rules. I'm hoping we can live with this until CSS3 line box[1] defines the ''include-ruby'' and ''exclude-ruby'' values for authors to avoid such cases. This ''auto'' value is trying to cover only 90% or so cases, not perfect.

[1] http://dev.w3.org/csswg/css3-linebox/


Regards,
Koji

-----Original Message-----
From: Koji Ishii 
Sent: Wednesday, December 08, 2010 12:48 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

Thank you so much for your help, Dave.

Although our idea seems to be close, it looks like we need to discuss a little more details.

Unfortunately, I started to have feelings that what I want could be what you don't prefer. To make sure I understand correctly, please allow me to write what I want ideally, because you must be far better and far more professional to come up with how to make it work. If what I want turned out to be what you don't like to implement, I hope we could then discuss further how to find a good way to resolve the situation.

I have three common cases in mind I want to cover in the ideal world.

When the author has very little knowledge of typography, s/he would use English default value:
  P { } /* usually with some top/bottom margins and line-height default is 1.2 */ In this case, ruby is likely to overlap the previous lines within the P blocks, but the first lines of P blocks are likely to be okay thanks to the top margins. I want lines with ruby moved down to avoid overlaps in this case.

The second case is when the author has enough knowledge of Japanese typography, s/he would use:
  P { margin-top:0px; margin-bottom:0px; line-height:1.8; } In this case, ruby will not overlap thanks to the line-height, and therefore the every line pitch should be consistent regardless whether a line has ruby or not (exclude-ruby behavior).

The last case is when the author knows Japanese documents use no before/after margins for P, but doesn't know increasing line-height, or intentionally use small line-height for small devices:
  P { margin-top:0px; margin-bottom:0px; } /* line-height is default (1.2) */ In this case, ruby is likely to overlap the previous lines within the P blocks and also cross blocks. Again, I want lines with ruby moved a little downward to avoid overlaps.

If I understand what you said correctly, your current code already covers the first case, but not the rest. Do I understand correctly? Maybe I misunderstand what you said "margin" is. When line-height is 1.8, there should be some spaces over/under the text. Is the space "margin" in your words? If so, probably I hate to say this but what I'm asking is to allow intrusions to the margins.

And yeah, the even more complex cases, as you said, the vertical-lr case, and when ruby-position:after[1] or text-emphasis-position:under[2], the next line must be moved down. I understand this must make things even more complicated.

I think this covers pretty much of what I would like to happen in the ideal world, and I guess some of these are not easy to implement. 

As I said, I would be happy to postpone some cases that are too difficult and/or too costly to implement at this point. I have some priorities in my mind, but I'd like to verify with some experts before finalizing them, and some--like vertical-lr or text-emphasis-position:under--need more investigations.

Will you please tell me which part of the ideal world are difficult to implement from your point of view?


[1] http://dev.w3.org/csswg/css3-ruby/#rubypos
[2] http://dev.w3.org/csswg/css3-text/#text-emphasis-position


Regards,
Koji

-----Original Message-----
From: David Hyatt [mailto:hyatt@apple.com]
Sent: Tuesday, December 07, 2010 2:25 PM
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 6, 2010, at 11:07 PM, Koji Ishii wrote:

> Dave,
> 
> I'm sorry to bringing up once-agreed issue again, but I think I underestimated the case of "cross blocks" cases.
> 
> If I understand this correctly, the "cross blocks" cases you mentioned should include the cases when ruby is at the first line of <p> element, it cannot detect whether it intrudes the last line of previous <p> element. Do I understand this correctly?
> 

No.  Right now WebKit doesn't attempt to cross blocks, so in the case of two <p> elements with no margins between them, WebKit will just assume the Ruby needs space and grow the height of the first line in the second <p> if it has a Ruby on it that overlaps the previous <p>.  When I referred to crossing blocks, I was actually talking about the case where the two <p> elements *do* have margins such that the Ruby could sit in the margin.  That is the case WebKit can't handle right now.

It's not too bad to handle it though if we decide that this should work.  For vertical-rl and horizontal-tb it's pretty easy to detect that you could fit in the collapsed margin area, but vertical-lr is harder. You don't yet know how big the collapsed margin is going to be in vertical-lr, so you'd have to carry along the needed space and wait until the collapsed margin got resolved to figure out if subsequent lines had to move.

If we do let Ruby go into margins, I'd prefer if we limit the check just to the margins and don't try to look at lines in previous blocks.

> In Japanese documents, following properties are usually set:
> 
>  p { margin-top:0px; margin-bottom:0px; }
> 
> In this case, it is quite possible that the ruby at the first line of <p> can overlap the last line of previous paragraph in the same level as lines within blocks.
> 

Yeah that case is not an issue.  The issue is that WebKit won't let Ruby sit in the margin area between blocks or at the top of pages or the top of the document.  It is possible for me to implement this though, as I said above.  It's mostly just that vertical-lr would be annoying.

dave
(hyatt@apple.com)

Received on Wednesday, 8 December 2010 09:04:39 UTC