W3C home > Mailing lists > Public > www-style@w3.org > June 2007

Re: Réf. : Re: Stylings only possible with Tables

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 24 Jun 2007 10:27:19 -0700
Message-ID: <002101c7b687$b95e3e70$3501a8c0@TERRA>
To: <www-style@w3.org>, <leslie.brown@evidian.com>


----- Original Message ----- 
From: <leslie.brown@evidian.com>
To: <www-style@w3.org>
Sent: Sunday, June 24, 2007 3:59 AM
Subject: Réf. : Re: Stylings only possible with Tables


>
> James Elmore proposed:
>> Markup:
>> <body>
>>   <div id=header />
>>   <div id=body />
>>     <div id=leftbar />
>>     <div id=content />
>>     <div id=right />
>>   </div>
>>   <div id=footer />
>> </body>
>> and styling
>> div#body { flow:horizontal; height:*}
>> div#body > * { height: * }
>> div#body > div#content  { width: * }
>>
>> All blocks inside div#body will be placed horizontally
>> in single row (flow:horizontal)
>> and will have height of content box of div#body
>> (second CSS rule)
>> div#body will take height left from #header and #footer
>> in the view (first rule).
>> And div#content will take full height of #body
>> and width left from #leftbar and #rightbar (third rule).
>
> I like the idea, which corresponds to what many of
> us find quasi-impossible to achieve without tables.
>
> Could it also be achieved via a "blocky" variant
> of float?
> . Same markup
> . Styling
>    div#leftbar { float: left, blocky }
>    div#right   { float: right, blocky }
>    div#content { float: blocky }
> where "blocky" says: the floated element extends
> to the full height of its containing element after
> all the content of the latter has been resolved.
>
> This would, for example, allow you to set the
> background of a sidebar on the sidebar itself
> rather than having to kludge it on the container
> (so easy with table cells!).
>

'float' is already "overused" for layout purposes [1].
I do not think it makes sense to give floats more
meaning that they had initially - blocks linked
to some position in text.

Main problem with floats is that determination of
float container has so many "if"s that layout behavior
is near chaotic already.

In contrary attribute flow: vertical | horizontal | h-flow | v-flow
is easy - it simply defines "layout manager" for any block container
(display-model: blocks-inside)

(See for example rendering of flow: v-flow - multicolumn layout
http://terrainformatica.com/w3/multi-column.jpg)

Another thing about your "blocky" - it is about only content
box dimensions.  In contrary flex units (percentage from free space)
can be used for all other dimensions too.

div#container { flow:horizontal; }
div#leftbar     { width: Xpx; height:*;  }
div#rightbar   { width: Ypx; margin-top:1*; margin-bottom:2*; }
div#content   { width: *; max-width: max-intrinsic; height:*; }

div#rightbar will be positioned in the row, its height will
take its intrinsic value, but top and bottom margins
will take rest of vertical space of the row in proportion 1:2.

div#content will have width spanning all available space in the row
but not wider than its max-intrinsic size. (rule #4)

So flex units allows you to do vertical positioning of elements
staying in normal flow (position:static). That is good in many
respects.

> Minimal impact on incremental rendering (?).

If float is used for its main purpose - inlining something in text -
then incremental rendering is not an issue.
If floats are used for main layout of the site then - yes -
it is not incremental rendering friendly.

In contrary flow attribute supports incremental
rendering naturally - as soon as you have some content
exceding some container then there is no free space in this
container so no flex units calculation required.
Algorithm is simple, predictable and understandable by human.

>
> I'm guessing that if the container has other content
> without "float: blocky" defined it should be treated
> as though it was a single blocky div, i.e. fills the
> remaining horizontal space and stretches the container
> if it's taller than the floated siblings.

Yep, this too. What if container has also text?

Too many unknowns. Trust me - no one from
browser vendors will want to redesign their existing float
layout module. It is too complex (read: fragile) already.

>
> So, in fact (just thinking aloud here) you could
> specify "float: blocky" (or "float-strategy: blocky"?)
> on the containing element instead and get fairly
> reasonable results in older browsers. This would
> also avoid the confusion that might arise if a div
> contained some floats with and some without the
> blocky parameter.
>
> And I wonder if a "blockx" variant that triggers
> the same automatic filling along the x axis rather
> than the y axis might be useful for languages where
> text flows vertically rather than horizontally.
> Of course you'd then need float:top and
> float:bottom.
>

Again, 'float' was not designed for such cases.

In contrary 'flow' attribute can easily be added to
existing engines as it just establishes LayoutManager [2]
mechanism for block container - adds new values
to existing flow:vertical (standard layout manager of
<div> block).

Andrew Fedoniouk.
http://terrainformatica.com

[1] http://dbaron.org/log/2005-12
[2] http://java.sun.com/docs/books/tutorial/uiswing/layout/visual.html
Received on Sunday, 24 June 2007 17:48:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT