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

[css3-floats] Comments on floats/positioning draft

From: David Hyatt <hyatt@apple.com>
Date: Wed, 27 Jul 2011 13:29:55 -0500
Message-id: <C8259E34-5927-4CCE-ACA7-D4A6319EC8FB@apple.com>
To: "www-style@w3.org CSS" <www-style@w3.org>
I am commenting on the draft at http://www.interoperabilitybridges.com/css3-floats/

In section 2.1, there are rules for floats:

"The static position of a positioned-float box is determined once prior to reflowing any content around the position-floated box. Note that this avoids any circular dependency of static position from reflow due to interaction of positioned-float with other content."

I don't really understand how layout is supposed to work. The normal layout order in say WebKit is to lay out your normal flow descendants and then to lay out your positioned objects. With positioned floats, you're turning that on its head. The normal flow content is now dependent on the layout of the positioned objects, so how do you handle this?

How many passes is the algorithm supposed to be? Are you hoping for a 2-pass algorithm? An n-pass algorithm?

One possibility is to simply lay out the normal flow content ignoring all the positioned floats, and then once you've determined your box dimensions, you place the positioned objects, and then if any are floating, you lay out again. However it seems like this could just result in a yo-yo effect as the block continues to change size as a result of flowing around the positioned objects.

The draft seems to be attempting to say something here with the static position comment above, but there are any number of other positions that could result in a circular dependency. bottom:0 for example on an auto height containing block.

You need to outline exactly what the layout order is here so that it's possible to implement this, because right now I have no idea what the expected results should be.




"A positioned-float box intersects with other elements in the same or other block formatting contexts. Note that this may cause elements to overlap and they may not be floated around the positioned-float box in all cases."

It sounds like you're saying that a positioned float can intrude into other block formatting contexts, but do you just mean in the normal flow? It seems odd to me that say overflow:auto/scroll/hidden or multi-column children or flex boxes would honor a positioned float intrusion by default, but it's hard for me to tell what is meant by this sentence.

"A positioned-float box may be positioned outside of its containing block, but the normal flow outside its containing block is not affected."

You may want to clarify that this applies even if the float is only partially outside the containing block.




"page
(New) The box's position is calculated according to the 'absolute' model, but in addition, the box containing block is always the initial containing block. As with the 'absolute' model, the box's margins do not collapse with any other margins. In the case of the print media type, the box is rendered only on the initial page. UAs may paginate the content of paged boxes. Note that CSS Regions are also initial containing blocks, in accordance with section 3.1 of the CSS Regions Module."

Here you say that the value of "page" is the initial containing block, but this makes no sense to me. The keyword is "page", so to me that implies that you're being positioned with the page area of the page you're found on as your containing block.  The ICB is always just the first page.

Later statements seem to contradict the above definition:

"A positioned float embedded in the content will be positioned 50px from the bottom edge of whatever page the positioned float is rendered in."

So which is it? I think a value of "page" is nonsensical if it just positions you on the first page only.

I find the examples with position:page and positioned floats to be completely incomprehensible.  I can't even tell what you're saying.



In 2.3:

"Otherwise, if 'position' has the value 'absolute', 'page' or 'fixed', and the value of 'float' is 'none', the box is absolutely positioned and floated. The 'display' is set according to the table below. Positioning of the box will determined by the 'top', 'right', 'bottom' and 'left' properties and the box's containing block."

I suspect something got screwed up here and you meant to say the value of "float" is 'positioned'? I don't see why a box would be both positioned and floated if the value of float is 'none'.




In 2.5:

"Positioned float elements that intersect the current element will not be respected in the inner flow of the element. Note that for block or table elements which have the 'overflow' property set to auto, scroll, or hidden, the flow-wrap value computes as 'none'."

It sounds like flow-wrap is preventing the intrusion of positioned floats into normal flow descendants. That seems fine to me, but I think the default should be 'none' for any descendant that established a block formatting context. It doesn't seem right to limit it only to overflow:auto/scroll/hidden. I'd expect a definition based off BFC establishment to be more forward-thinking and general (e.g., it could apply to flex box and multicolumn descendants).



Final thoughts:

Overall I like the syntax and the idea of using positioned floats. I'd still like to see some additions to positioning to allow you to easily center an object (the ability to align a point in the positioned element with a point in the containing block basically).

You just need to define how the layout of positioned floats is supposed to work, since right now I can't tell what I'm supposed to do to implement them. An n-pass algorithm scares me, so I'm kind of hoping we could limit it somehow.

dave
(hyatt@apple.com)
Received on Wednesday, 27 July 2011 18:30:24 GMT

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