W3C home > Mailing lists > Public > www-style@w3.org > January 2008

Re: flowing around both sides of a float

From: Brad Kemper <brkemper@comcast.net>
Date: Tue, 1 Jan 2008 13:59:15 -0800
Message-Id: <E3F0FD7B-00EC-4C6F-B457-1613E9333756@comcast.net>
Cc: www-style@w3.org, David Woolley <forums@david-woolley.me.uk>
To: John Oyler <johnoyler.css@gmail.com>

On Jan 1, 2008, at 12:31 PM, John Oyler wrote:
> On Jan 1, 2008, at 3:21 PM, Brad Kemper wrote:
>> On Jan 1, 2008, at 6:27 AM, David Woolley wrote:
>>> James Elmore wrote:
>>>> some of the proposals will be difficult to implement. Also, some  
>>>> will not be immediately used, simply because they are not known  
>>>> to be available. But providing tools which make CSS a more  
>>>> complete system of styling documents will make CSS a more useful  
>>>> tool set.
>>> One of the things that makes a good computing standard is that it  
>>> achieves a lot with a little.  One of the things that leads to  
>>> the eventual death of computing standards is that whilst they  
>>> start that way, they eventually try to do everything.  As a  
>>> result they get too complex (CSS is already well beyond the point  
>>> where most authors understand it well enough to be able to know  
>>> whether there are features to do things they want).
>> In this case (float:center), the "float" concept is well  
>> understood, and "center" is a common value to accompany "left" and  
>> "right" as keywords to describe horizontal position. Authors will  
>> not have a hard time understanding the addition of the "center"  
>> value to the "float" attribute. They may, on the other hand, have  
>> a hard time understanding why it is missing.
>> Float (or something like it) would be especially useful if it  
>> could be positioned absolutely, yet still affect the flow (so that  
>> inline elements and other traditional floats did not overlap it,  
>> and would be effected by its margin). The details of how that  
>> would work would probably be more complex, but the effect that  
>> float:center should have is pretty clear.
> It isn't clear how this could work. Float:absolute, and then it  
> uses left/right/top/bottom for positioning? I'm all for  
> float:center in principle at least, but at least I could wrap my  
> head around how it's supposed to work. Something more flexible  
> isn't as obvious even when I spend time thinking it through. Also,  
> would there be any point in a float:center if it were implemented?  
> If you can derive one behavior from the other...
> John Oyler
> john@discrevolt.com

Two different things:

1. Float:absolute is not clear yet, and as I said, while useful,  
would be more complex to sort our exactly how it would work. Requires  
further discussion. Is that what you are asking about? I view it as a  
separate topic, and float:center should not be dependent on the  
acceptance and implementation of float:absolute (which I would  
imagine would take longer to finalize and implement). Being a bit of  
a chimera between absolute positioning and float, I imagine it would  
be almost identical to position:absolute, except that it would have  
margin (default would be margin:0). The complex part is determining  
which block level elements, if any, would be affected by the margin.  
Descendants only? Descendants and siblings? Cousins (descendants of  
parent's descendants)? Or inline content only, regardless of where it  

2. float:center is what I said is pretty clear. It would work just  
like float:left and float:right in most regards, which would continue  
to work as they do now. Item would move to center, and text (and  
other inline content) would flow around it in the direction of the  
text. The flow of text would stop at the item and then continue on  
the other side. Additional non-clearing floats would line up to the  
right of the first (in LTR flow), if they fit, with their combined  
width centered in the parent element. Additional elements with  
float:center and clear:[ center | both | all ] would appear  
underneath. The "both" value for "clear" would be deprecated in favor  
of the more standard "all" value, and would continue to work as a  
synonym for "all".
Received on Tuesday, 1 January 2008 21:59:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:32 UTC