Re: Clarification needed for inline boxes containing block boxes

2009/2/27 Andrew Fedoniouk <news@terrainformatica.com>:
> Boris Zbarsky wrote:
>>
>> Giovanni Campagna wrote:
>>>
>>> Can my text be the solution?
>>>
>>>> The resulting inline boxes should look exactly as they were contiguous
>>>> in DOM, but owned by different line boxes (ie with a line break inside
>>>> the inline box)
>>
>> I think so, yes.
>
> Could you explain then why these two spans should look
> so "dramatically" different?:
>
> <!DOCTYPE html>
> <html>
>  <head>
>    <style>
>      span div { border:1px solid; }
>      span { padding: 0 20px; background: green; border: 2px solid red }
>    </style>
>  </head>
> <body>
>  <span>aaa<div>bbb</div></span><br/>
>  <span>aaa<div style="display:inline-block;
>              width:100%;">bbb</div></span>
> </body>
> </html>

Because they are different: one creates an anonymous a block box,
containing another anonymous block box, with a line box, with an
inline box, connected to the span; sibling of the second block box, a
new block is created, this time esplicitly, with line and inline
boxes; lastly: a new anonymous block box, with line and inline boxes,
the latter connected with the inline level element. That is, inline
boxes created by the inline level element "<span>aaa</span>" are not
ancestors of the <div> generated block boxes (this is not possible,
only block, inline-block, table-cell, column and page boxes can
contain other block boxes). They're not siblings either, because the
sibling of a block box can only be a block box.
Summing up boxes and associated elements:
-block --> anonymous
   -block --> anonymous
      -line
         -inline  --> <span>"aaa"
   -block --> <div>
      -line
         -inline -> "bbb"
   -block --> anonymous
      -line
         -inline --> "aaa"</span>

As you see, properties set on <span> are completely unrelated to those
on <div> (apart from inheritance), so the background and borders are
not propagated to <div>

The second example instead creates an anonymous block box (required by
the first example, otherwise it would have used the <body> block box).
Inside this box, initally a line box is created, that contains the
root inline box, generated by <span>, that in turn contains generated
by "aaa", then an inline-block for <div>, then another inline box for
</span> (created because of padding and margin, see CSS21 9.4.2).
This is therefore the initial box tree:
-block --> anonymous
   -line
      -inline --> <span>
          -inline --> "aaa"
          -inline-block --> <div>
          -inline --> ""

Unfortunately, the line box is wider than the block box, so it
splitted into three line boxes as per normal line breaking rules.
Although CSS2.1 is not very clear about this, I expect that the
inline-block should be rendered as if it was an inline, replaced box,
with trasparent background.
Final box tree:
-block --> anonymous
   -line
      -inline --> <span>"aaa"
   -line
      -inline-block --> <div>
   -line
      -inline --> ""</span>
As you may see, in this example you only have one "block", and three
line boxes owned by the same block. This means for example that if you
set "line-height" on <body> (or a wrapping <div> that replaces the
anonymous block box), also the inline-block will move.

I know, this behaviour is far from intuitive, but as Boris said, this
is what spec currently says and what browsers do. It's too late to
change.

>
>>
>>> Yeah, of course block-in-inline. Well, they wrote invalid HTML, so
>>> they should have expected non consistent rendering.
>>> In addition, rendering is not consistent even now, so I don't think
>>> there are sites like that, as long as they test in IE6/7 and FF2/3
>>> (the most used browsers)
>>
>> Rendering is only inconsistent if you set borders or padding on the
>> inline.  Rendering without that is pretty consistent....
>>
>> -Boris
>>
>>
>>
>
> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>

Giovanni

Received on Friday, 27 February 2009 15:03:05 UTC