Discussion: Float and Shrinkwrap
Afficher un message
Vieux 10/04/2008, 22h43   #46
Ben C
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Float and Shrinkwrap

On 2008-04-10, Gus Richter <gusrichter@netscape.net> wrote:
> Ben C wrote:
>> On 2008-04-07, Gus Richter <gusrichter@netscape.net> wrote:
>> [...]
>>> In my examples, "wrapper" and "containing block" are two different things.
>>> The "wrapper" is simply used to reposition the segment pairs. In your
>>> examples in the link I mention above, you use headings to accomplish
>>> this w/o wrappers.
>>> The "containing block" is each one of the yellow boxes in every one of
>>> your examples on the page linked above (yellow boxes in my examples as
>>> well). It is a bit counter-intuitive in that normally a container comes
>>> first in the markup, but in the case with floats, the "container block"
>>> comes _after_ the float.

>>
>> No the containing block for a float is always above it in the document
>> tree.

>
> I was trying to say that it was counter-intuitive because in the
> markup/source the normal would be to have the float come _second_ as:
>
> <div id="shrink">
> <div id="float">Some text and more</div>
> Some text and some more to get a few more lines.
> </div>
>
> when compared to where the float comes _first_:
>
> <div id="float">Some text and more</div>
> <div id="shrink">Some text and some more to get a few more lines.</div>


OK, but in these two examples the containing block for the float is
different. In the first one it's #shrink, in the second it's BODY or
whatever's immediately outside #float and #shrink.

The text in #shrink flows around the float, but that doesn't mean it
shares the float's containing block.

Floats often overflow their containers vertically and any inlines that
are in the way have to get out of the way, regardless of whose
containing block they are in.

The damage caused by a float is however restricted to its block
formatting context (often higher up the tree than the local containing
block).
  Réponse avec citation
 
Page generated in 0,05224 seconds with 9 queries