Re: Block Model Additions: Float Positioning

On Jul 20, 2007, at 10:10 PM, Eli Friedman wrote:

>
> --- James Elmore <James.Elmore@cox.net> wrote:
>
>> I want to start with a discussion of adding
>> ‘position’ to the
>> parameters of the ‘float’ styles. This will allow
>> users to  adjust
>> the positions of floated elements (or leave the
>> positions alone) more
>> than just ‘float: left;’ and ‘float: right;’ permit.
>
> [snip]
>
> Your proposal is quite complicated, and there isn't
> any significant discussion of how it would be used.
> Why exactly would someone want to position floats in
> arbitrary places on the page?

Fair enough. I have seen numerous requests, suggestions, and  
proposals for positioning floats in this mailing list in the last few  
months. If the half dozen different people that I have seen want this  
ability, there are probably enough more who haven't asked to make it  
worth while to discuss.

A 'float'

   1.  Moves the floating block to the left or right, adjusting for  
previous floaters.
   2.  Moves other blocks out of the way so the floating block fits.
   3.  Places the following blocks where they will fit around the  
floater, until the end of the floater.

Many ways already exist to position blocks in arbitrary places on the  
page. What they don't provide is ways to move other elements out of  
the way, as 'float' does. It seems strange to me that such a useful  
ability (to move elements and text out of the way) is limited to  
'left' and 'right'.

Many layouts, both on paper and on the screen, could be improved or  
simplified if floats had more positioning options. The example I gave  
in my previous email was Problem #4 in the Advanced Placement Draft  
(placing a float between two columns). I can also imagine that many  
web pages, which currently use the entire left side for a menu could  
be improved by using a float, where the entire width could be used  
for content after the menu ends. Further, many pages use 'sidebars'  
-- spaces for additional information or images, which may or may not  
be on the side -- these could also be floats, allowing them to be  
placed logically in the HTML document and someplace visually  
appropriate on the screen or paper.

>   What effect do you want
> to be able to achieve that cannot be done with current
> CSS?  That would be a much better way to start a
> discussion than an incomplete proposal.  I've tried to
> address some of your points, but it's rather difficult
> without really knowing what you're trying to do.
>

I would like to be able to have more options for 'float' than just  
'left' and 'right'.

I would like floats to span multiple columns, or the corners of four  
adjacent boxes.

I would like to be able to position floats in the middle of blocks  
and have text flow around them.

I would like to be able to move the float up or down, rather than  
limiting it to the starting height of the line of text where the  
float was declared. That way, I could guarantee that there would be  
exactly one line of text (or two, or ...) before the float starts.

I would like the float to be related to the enclosing block, rather  
than the text blocks where it is declared.

Even with the foreseeable problems, I would like (under some  
circumstances) to float a block (especially a menu) in relation to  
the viewport, where it would always be available. (Yes, this can be  
done with with 'position: fixed;' but objects underneath will be  
hidden, not moved out of the way. Either that or large areas of the  
page need to be left empty so nothing important is covered.)

>> I’m not sure exactly how flowing the text boxes and
>> blocks around the
>> ‘floated’ block would work, especially when the
>> floated element
>> extends into another block.
>
> It seems like you would benefit from spending some
> time reading the spec and understanding how floats
> currently work.  And how exactly flow works around
> these repositioned floats is probably the most
> important/tricky part of the proposal, and where most
> of the implementation work that would be required.
>

I've read the spec, several times; I've also read a number of books  
on HTML, XHTML, CSS, etc., all of which explain the current 'float'  
logic. Because I'm proposing that floats be allowed outside of their  
originating boxes, the new rules need to be worked out. Sorry if I  
don't understand the process yet. Should I propose a complete set of  
rules for flowing text, etc., around the new floated elements, even  
if what I suggest is wrong?

Because it is the most important and tricky part of the proposal, I  
was reticent to try and give a complete set of rules without some  
more experienced hands helping. I hoped that some people with more  
experience could offer suggestions. Is that only done after I make a  
first stab at the rules? Mostly what I have seen in this forum is  
that people respond with 'that will never work!' and that ends the  
discussion.

>> ‘Float: static;’ would not move the floated element,
>> only allow text
>> and blocks to flow around it.
>
> How is this different from float: left (at least for
> LTR text)?

'float: static;' would leave the floated element where it was, only  
make it a separate block and let the rest flow around it. If, for  
example, it is taller than the line height, it would have multiple  
lines of text around it, rather than making the line height adjust to  
the block height. For now, I imagine that the text (ltr) would reach  
the left edge of the floated block and start again after the right  
edge, making line boxes which have an empty place where the float is.  
I have seen this occasionally used to good effect. (I have also seen  
it abused, probably more often.) If the designer wants multiple  
columns with a block in the middle, this is a different problem and  
should be handled as multiple columns, not a float.

>
>> ‘Float: relative;’ would allow the floated element
>> to move along with
>> the text and blocks which surround it, just as a
>> ‘relative’ element
>> would, except the TRBL (top, right, bottom, left)
>> parameters could
>> move the floated object relative to its original
>> position. Perhaps
>> there could be another parameter which would permit
>> the empty space
>> where the floated object originally was positioned
>> to remain open or
>> to close, although the definition of 'float' would
>> already indicate
>> that the hole would close.
>
> What's the use of shifting a float some arbitrary
> amount?  Shifting it vertically seems worthless, and
> the only effect you could achieve with horizontal
> positioning would be some very difficult-to-read text.
>  (Something similar to this might be useful with
> columns, though.)

I'm not sure why you think vertical shifting is worthless. Yes, the  
float could be moved (up or down) in the HTML document, but because  
the logical structures of the HTML are often different than the  
visual structures desired on the page or screen, there are reasons  
for offsetting the floated element from its original position in the  
document order. (Isn't this what the Advance Layout group are  
proposing, only better controlled?)

To be honest, I feel (relative) this is the weakest part of my  
suggestion. Since the starting point, from which the float is offset,  
changes based on viewport width, font sizes, etc., offsetting from a  
hard-to-define position seems less useful than offsetting from a  
known (or at least relatively stable) position, such as the edges of  
an enclosing block.

>
>>
>> ‘Float: absolute;’ would allow the floated element
>> to be positioned
>> in relationship to the enclosing block. This would
>> be the closest to
>> the current ‘float: left;’ (or right), permitting
>> more accurate
>> positioning of floated elements, perhaps with:
>>
>>      float: absolute; top: auto; bottom: auto; left:
>> 0; right: auto;
>>
>> producing the same effect as ‘float: left;’
>
> I don't see what useful layouts this could achieve,
> especially considering that the web is not a medium
> which gives you the kind of strict control that would
> make this useful.

This seems the most useful to me. The offsets could be negative as  
well as positive, allowing floats to overlap between columns or  
between rows. Even if it were not terribly useful on low resolution  
screens, it would be very useful for @print media rules.

A blanket statement that 'it would not be useful for the web' doesn't  
carry much weight. Even if you and I together can't find something  
useful to do with this feature, there are thousands of designers who  
could use it for things we can't imagine.

The current feature set for floats is limited. The ability to 'float'  
an element is very useful and I see in the draft specs (which I  
haven't all read yet) several suggestions to expand the abilities of  
floats (I just looked at 'Grid Positioning' which wants to place  
floats in a grid.)

If 'position: absolute;' is useful, why not allow 'float: absolute;'  
That provides even more ability for layouts.

>
>> Finally, ‘float: fixed;’ would place the floated
>> element relative to
>> the viewport. This might be harder to program, since
>> the inline,
>> text, and regular blocks would need to be ‘reflowed’
>> every time the
>> viewport or the elements displayed in it changed.
>> (Perhaps this could
>> be delayed until a later release, although it seems
>> that it might be
>> very useful to designers.)
>
> Marginally useful for printing at best; can you
> actually imagine what it would be like to have text
> constantly moving around as you scroll?  (Not to
> mention it would be a huge perf hit to have to
> recalculate the layout of the entire page every time
> you scroll.)
>
> -Eli
>

This worried me, as well. The performance hit and the motion of  
elements as the viewport moved could be killers. On the other hand,  
imagine a web site with the most important information or controls  
always visible -- no more scrolling back to the top to find the menu.


Sorry if I am not presenting these suggestions in the correct order.  
I am still finding my way around the process.

Thank you for your responses. I enjoy the discussion and hope that  
others can see the utility in what I suggest or see other ways to  
improve CSS because something I said triggered an idea.

Received on Saturday, 21 July 2007 21:40:36 UTC