Re: [css3-gcpm] float:center

On Jan 5, 2008, at 3:41 PM, Brad Kemper wrote:

> (Some stuff deleted, just to save space.)
>>
>> I don't particularly like that float-offset combines positioning  
>> and definition of anchor point. I love the concept but I would  
>> rather see separate simpler properties (perhaps "anchor-point"?).
>
> "anchor-point" (or maybe just simply "point") would basically be a  
> coordinate combining top and left, right? If we have that (and I am  
> not for or against it), then it should be able to be used for any  
> property that can take numerical unit values for top and left, such  
> as background-position, left and right as they relate to  
> "position:", etc. Of course then you have the problem of it not  
> being useful when you want to position by the right or bottom. So  
> top, bottom, right, and left still need to be indicated somehow. So  
> perhaps like this, as an alternative to the above, for positioning  
> floats within blocks of columns:
>
> 	float:absolute column; top:0.5gr; left:0.5gr;
>
> Also, I don't particularly like that "float: right column" means  
> that it goes in the right column, and not the right side of the  
> column, and that "float:right" means that it it floats to the right  
> side of the current column. It sounds backwards.

To position an element, we must specify a point of the element which  
will be aligned with a point of the aligning element (the containing  
block, for example. We may simplify and always require the point of  
the element being 'floated' to be the (top, left), but that is not  
the only way to align elements -- maybe it would be simpler (in some  
cases) to align the center of the 'float' to the center of the  
containing block. Other cases jump immediately to my mind, I'm sure  
most of you can think of at least a few, as well.

The current 'floats' (left and right) align the top with the top of  
the current line box (if I read the spec. correctly) and either the  
left edge with the left edge of the containing block, or the right  
edge with the right edge of the containing block. Expanding this to  
allow alignment with different points of a 'floated' element and with  
different containing blocks (possibly current column, current block,  
another named block, and/or the viewport) would make them much more  
useful for placing content and having text flow around that placed  
content.

>
> I don't think "column" (or "page" in the earlier portion of that  
> working draft) should be part of "float", anyway. That specifies  
> the container to which the coordinates applies, but that would be  
> also be very useful for  other positioning schemes, such as  
> position:absolute, and maybe even position:relative. So, inasmuch  
> as it relates to this draft, I would prefer something like the  
> following to center it between the first and second column, 1/2 :
>
> 	float:absolute; top:0.5gr; left:0.5gr; container: column;
>
> By extension, to float it to to the top of the right-most column  
> (i.e. the right side of the box), you would do this:
>
> 	float:absolute; top:0; right:0; container: block;
> 	/* or maybe "container:parent;" */
> 	/* or maybe "container:default;" */
>
> This might also be used to address David Wooley's concern about  
> where in the HTML document you put something like a pull quote or  
> illustration, which relates more to the entire article or possibly  
> the whole page than to any particular column you might stick it in.  
> Using the above, you could put the pull quote at the begging or end  
> of the article.
>
> If this was extended further, to specify any block as a container,  
> it would be even more powerful. For instance, consider the  
> following, which would allow you to put the html for the pull-quote  
> or image (or whatever) anywhere in the document:
>
> 	float:absolute; top:0; right:0; container: id(myColumnBox);
>
> This also seems simpler and more straightforward than the "named  
> flows" of the same working draft [2].
>
>> * It isn't well defined how text floats around all possible page  
>> floats. I agree that it rarely makes sense to wrap text on both  
>> sides of a float. I don't want to say however that it never makes  
>> sense.
>>
>> It is a design decision and should be made by the author, not  
>> restricted by technology.
>
> Thank you. Exactly a point I've tried to make, and James Elmore too  
> (if he doesn't mind my speaking for him on this small but important  
> point). It is good to read those words from an implementor, as  
> obvious as they may sound to some of us authors who like to design  
> creatively.

I should sign up with AOL. I agree.

>
>> BTW, when you combine page floats with tight wrap, wrapping on  
>> both sides of a float will suddenly make sense much more often...
>>
>> Floats should have their own control to say on which side(s) text  
>> is allowed to flow. Just like "clear" but applied to float.
>
> With float:right and float:left, it is defined, but I agree it  
> would be useful once we start positioning floats in other places.  
> Perhaps we could call it "flow", and have:
>
> flow:right (the default for float:left)
> flow:left (the default for float:right)
> flow:split (my preferred default for float:center or other  
> mechanisms that could allow inline content on both sides of a float  
> within a single column, but not valid on floats that cross more  
> than one column)

Except for floats in top-to-bottom and bottom-to-top languages, these  
are the only combinations I can come up with. With the use of 'start'  
and 'end' or 'before' and 'after', this becomes clearer. I can see  
some people saying 'but how can I know whether 'start' is to the left  
or the right?' My answer is -- 'Don't you know which direction your  
language fills? Start/before is at the beginning of the current line,  
whether it fills left-to-right or right-to-left or top-to-bottom.'

After consideration, I prefer 'wrap' to 'flow' as the latter is too  
close to 'float' and might be cause for confusion, or even for  
mistyping. (I already did it at least once.)


James Elmore