W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [css2.1] Issue 199 proposal

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 27 Mar 2011 19:32:33 +0200
Message-ID: <4D8F74B1.3050408@moonhenge.net>
To: www-style list <www-style@w3.org>
CC: fantasai <fantasai.lists@inkedblade.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
On 23/03/2011 05:31, fantasai wrote:
> On 10/25/2010 05:48 PM, Tab Atkins Jr. wrote:
>>
>> | If an element contains no text, no preserved white
>> | space, no inline elements with non-zero margins,
>> | padding, or borders, and no other in-flow content
>> | (such as images, inline block, or inline tables),
>> | then no line boxes are generated inside the
>> | element. The auto position of any child elements
>> | is the top of the box in the vertical direction,
>> | and the same position horizontally that a zero
>> | width, zero height inline replaced element would
>> | have if placed in the element. (This, for example,
>> | respects the text-align property.)
>
> So there are two problems with this formulation:
> a) It doesn't handle the case where such line boxes are siblings
> of block boxes, e.g.
> <div><p/><span/></div> or <div><p/><span/><p/></div>

But that's only because we're talking about elements when we should be 
talking about boxes, right?  (More precisely, block container boxes that 
establish an inline formatting context.)  If Tab's new proposal were 
formulated in terms of such boxes, the anonymous block box around the 
span in your examples would be the subject of the proposed text, and 
there would be no problem.

> b) It doesn't specify the contents' transparency wrt margin
> collapsing.

How so?  If no line box exists then there's no issue with respect to 
margin collapsing, which takes place according to the rules of 8.3.1. 
If, for example, in <p><span></span></p> the principal block box for the 
<p> has auto height and min-height and does not establish a BFC nor has 
clearance, then it contains no line boxes and the span is unrepresented 
in the box tree and rendering (assuming the span satisfies the relevant 
conditions), and the box's top and bottom margins are adjacent according 
to the new margin-collapsing wording.  If, on the other hand, it has 
non-zero height, then it still contains no line boxes and the span is 
still unrepresented, but margins don't collapse through the box.

> The original text was this:
>
> # Line boxes that contain no text, no preserved white space, no
> # inline elements with non-zero margins, padding, or borders, and
> # no other in-flow content (such as images, inline blocks or
> # inline tables), and do not end with a line feed must be treated
> # as zero-height line boxes. For the purposes of margin collapsing,
> # this line box must be ignored.
>
> Your earlier proposal was this:
>
> | Line boxes that contain no text, no preserved white space, no
> | inline elements with non-zero margins, padding, or borders, and
> | no other in-flow content (such as images, inline blocks or
> | inline tables), and do not end with a line feed must be treated
> | as zero-height line boxes for the purpose of positioning the
> | elements inside of them, and must be treated as not existing
> | for any other purpose.
>
> We might be better of working from your original proposal.
> How about this:
>
> | Line boxes are created as needed to hold inline-level content within
> | an inline formatting context. Line boxes that contain no text, no
> | preserved white space, no inline elements with non-zero margins,
> | padding, or borders, and no other in-flow content (such as images,
> | inline blocks or inline tables), and do not end with a preserved
> | newline must be treated as zero-height line boxes for the purpose of
> | determining the static positions of any elements inside of them,
> | and must be treated as not existing for any other purpose.

I don't quite get the last bit of this and Tab's old proposal, but I 
think you're referring to the fact that it's not well-defined where to 
position an absolutely positioned or floated box in the case that they 
don't give rise to any rendered boxes when trying to calculate their 
"static position".  (Let's define the "static position" of a float, 
analogously to abspos elements, to be the position of the top-left 
margin box corner that its first box with 'display' other than 'none' 
would occupy if the specified 'float' value had been 'none'.) 
Specifically, if the span is floated or abspos in <p><span></span></p> 
then the spec doesn't define where to position it.

For abspos boxes, the spec merely overlooks that case; the position of 
abspos boxes is otherwise well-defined.  For floats, the spec is even 
more confused.  9.5 says:

   # A float is a box that is shifted to the left or right on the
   # current line.

(Spec assumes there is a line box.)

   # If there is a line box, the outer top of the floated box is aligned
   # with the top of the current line box.

(Spec recognizes that there may or may not be a line box.)

   # [...] if inline-level boxes are placed on the line before a left
   # float is encountered that fits in the remaining line box space [...]

(Spec assumes there is a line box.)

   # 4. A floating box's outer top may not be higher than the top of its
   #    containing block. When the float occurs between two collapsing
   #    margins, the float is positioned as if it had an otherwise empty
   #    anonymous block parent taking part in the flow. The position of
   #    such a parent is defined by the rules in the section on margin
   #    collapsing.

(Spec describes what to do when there is not a line box.)

I think that we should fix these flaws where absolute positioning and 
floating are defined rather than try to work around them in the Issue 
199 paragraph by introducing imaginary zero-height line boxes.  After 
all, there are loads of places in the spec where we calculate a 
tentative this or a hypothetical that under assumed temporary 
conditions, and we don't write portions of the spec to make explicit 
allowance for that. Rather, the spec should be tight enough so that 
everything automatically works under whatever assumption albeit giving 
rise to a possibly different box generation and rendering when the 
assumption is later removed.

Moreover, it's not clear how a zero-height line box is supposed to 
function.  Does it mean the assumption of "font-size:0" (zero-height 
strut) and "line-height:0" (zero minimum line box height)?  Note that 
the line box height would still actually be positive if the 
floated/abspos box is inline-level with positive height when determining 
the static position.


To summarize, I don't think we should introduce imaginary zero-height 
line boxes in the Issue 199 paragraph.  Instead, we should clean up how 
9.5 and 9.6 specify how floats and abspos boxes are positioned, treating 
separately the cases where the static-position first rendered box is 
inline-level, block-level, or non-existent.


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Sunday, 27 March 2011 17:33:07 GMT

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