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

Re: flowing around both sides of a float

From: James Elmore <James.Elmore@cox.net>
Date: Wed, 2 Jan 2008 10:02:53 -0800
Message-Id: <3ABF3FE4-A99F-490C-A677-F62389D6081E@cox.net>
To: Brad Kemper <brkemper@comcast.net>, CSS <www-style@w3.org>

On Jan 1, 2008, at 1:59 PM, Brad Kemper wrote:
> 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 exists?

This is one reason why I prefer to separate the ability to 'float' an  
element into a position and the ability to flow (or 'wrap') elements  
around the 'floated' element. There are already some good, well  
documented, reasonably complete, and even implemented ways to  
position elements. What is lacking is the ability to make other  
elements move around them as a 'float' does. Why make 'float' more  
complex when it could just be a shorthand way of saying 'position:  
absolute left; flow: right;'. (If I got the syntax wrong, I  
apologize; I just wanted to point out that 'float' is doing two  
things, and it should be possible to handle the two different things  
separately, as well as the shorter 'float: left;')

Since CSS now handles top-to-bottom and bottom-to-top text as well as  
left-to-right and right-to-left, float parameters need to change from  
'left' and 'right' to 'start' and 'end' to handle floats in vertical  
text. (Or should that be 'before' and 'after'?)

> 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".

Let me see if I can list the different ways where 'text' (actually  
any inline elements) might need to clear: LEFT (START), RIGHT (END),  
(END_CENTER), and ALL. The first three are the individual 'float'  
parameters. The next three (sides, left_center, and right_center) are  
the ways of combining float parameters two at a time. ALL is for all  
three types of (proposed) floats.

Now, for my proposal to allow 'flow' or 'wrap', I therefore need  
parameters for 'before', 'after', and 'both'. Since the flowing  
elements can only be before the 'float' (float: right; in English  
text); after the 'float' (float: left; in English text); and on both  
sides of the float, if the floated element is somewhere in the  
middle. These are the only cases I can think of, even considering  
that a floated element might overlap multiple other blocks or  
columns. Can anyone else out there see any cases I have missed? I  
guess it might be possible that someone wanted text in a left column  
to wrap and text in a right column to clear, but that would be  
handled by the 'clear' styles.

James Elmore
Received on Wednesday, 2 January 2008 18:03:20 UTC

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