Re: [css3-gcpm] maybe-floats vs "in-flow"

On 24/08/2012 00:44, Håkon Wium Lie wrote:
> Also sprach Peter Moulder:
>
>   > > I think that the spec should at least draw attention to this sort of
>   > > consequence of the float-or-in-flow decision for such a box.
>   >
>   > In particular, the existing specified behaviour as I understand it
>   > has significant implications for the architecture of print-based UAs
>   > (or other non-interactive UAs), which might not otherwise have any need
>   > to be able to make such deep modifications to the box tree after the
>   > initial box tree is created and layout (coordinate assignment) has begun.
>
> It seems that we should make element floats if there's a chance of
> them becoming floats. I've added this text to the draft:
>
>    An element is considered to be a float if it has a snap() value,
>    even if the element does not appear within the specified distance.
>    This way, it can be determined whether an element is float or not
>    without laying out the document.
>
>    http://dev.w3.org/csswg/css3-gcpm/#page-and-column-floats

Just to confirm: even if a snappy float doesn't actually snap, it's 
still a float and therefore has all the properties that a normal float 
has, including:

   (a) establishing a new non-inline formatting context; and hence:
     (i) its margins do not collapse with its children
     (ii) it provides the "scope" for floated and 'clear' descendants, 
expanding its height as necessary to contain them
   (b) special width calculations
   (c) special layout interactions with other floats (and in particular, 
its margins do not collapse with those of its siblings)  and indeed 
other BFC-establishing boxes in general

?

Seems reasonable since you probably want most of those behaviours 
anyway.  Not sure about killing the possibility of margin collapsing 
with siblings (assuming we're working inside a block formatting context) 
though.  I think one could argue that margin collapsing with siblings is 
desirable if the maybe-float doesn't float.  Still, it sounds like it's 
not worth the implementation hassle to worry about having conditional 
margin collapsing.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Monday, 8 October 2012 10:25:16 UTC