RE: [css3-floats] Comments on floats/positioning draft

The proposed spec you're reading is a bit outdated at this point. We are working on a new version that will replace the CSS Exclusions editor's draft that will include modifications to answer the concerns you have. 

In short. The processing model as of now is a 2-pass layout exactly as you outlined it below. And, yes, this model doesn't solve the bottom:0px inside of auto-height container problem (that and few more open questions are still pending resolutions). 

As to what is affected by an exclusion - all elements besides inline that are contained inside of the same subtree as the exclusion itself. This concept should also be clear in the new spec.

Rossen

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On 
> Behalf Of David Hyatt
> Sent: Wednesday, July 27, 2011 11:30 AM
> To: www-style@w3.org CSS
> Subject: [css3-floats] Comments on floats/positioning draft
> 
> 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, 3 August 2011 20:24:36 UTC