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

Re: [css-ruby] Anonymous Box Generation and White Space Handling Rewritten

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 02 Jul 2014 11:53:39 -0400
Message-ID: <53B42B03.7050507@mit.edu>
To: www-style@w3.org
On 7/2/14, 9:14 AM, fantasai wrote:
> Please review and comment on the changes.

1)  Say I have this:

   <div style="display:ruby"><div style="display: ruby"></div></div>

Stepping through the section 2.2 algorithm, step 3 explicitly does 
nothing in this case, since it excludes "ruby containers".  Steps 4 and 
5 are not relevant since there is no white space.  Step 6 is not 
relevant because there are no ruby bases and no white space.  Step 7 is 
not relevant because there are no ruby containers (base or annotation) 
and no white space.

So the upshot is that this box structure is left as-is.  Is this 
actually purposeful?  I would have expected the inner ruby container to 
get wrapped in a ruby base and ruby base container...

2)  Assuming #1 gets addressed as I suggest, I believe the definition of 
"inter-level whitespace" can be simplified to two patterns:

   I. Next box is ruby annotation container
   II. Next box is ruby annotation an previous box is ruby annotation

   Any intra-ruby white space whose immediately following sibling is a
   ruby annotation container or whose imme

3)  The table in step 5 doesn't say what happens to intra-ruby white 
space which has a ruby base previous box and ruby base container next 
box (or vice versa).  Either it should classify it (most likely), or 
this white space should be removed as inter-level white space?  Or does 
it just hang around as ruby bases?

4)  What should happen to whitespace between two consecutive ruby base 

5)  This markup:

   <div style="display:ruby">
     <div style="display: ruby-text"></div>
     <div style="display: ruby-text"></div>

and this markup:

   <div style="display:block">
     <div style="display: ruby-text"></div>
     <div style="display: ruby-text"></div>

   have quite different behavior per current spec: the former ends up 
with a single ruby annotation container containing both kids, while the 
latter ends up with two ruby containers each of which contains a single 
ruby annotation container containing a single ruby annotation.  Is that 
the desired behavior in this case, or a spec bug?  This bit seems 
related to the issue in 

Received on Wednesday, 2 July 2014 15:54:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:44 UTC