Re: Wrapping delimited lists, fluid rows

Andrew Fedoniouk wrote:
> In htmlayout engine (html/css engine) I've added two things
> for that:
> 1) attribute  flow: vertical | horizontal | h-flow | v-flow [1]
> 2) flex length unit: %% [2]
> 
> So to define let's say left-sidebar - content - right-sidebar
> layout that is stable for the content it is enough to say:
> 
> <div id="body" style="flow:horizontal">
>    <ul class="leftbar" ><ul>
>    <div class="content"></div>
>    <ul class="rightbar" ><ul>
> </div>
> 
> .leftbar , .rightbar
> {
>     width:20em;
>     height: 100%%; // full height of the #body content box
> }
> 
> .content
> {
>     width:100%%; // all space left from leftbar and righbar
>                            // in the #body content box
>     height: 100%%; // full height of the #body content box
> }
> 
> So this create expandable single row layout.
> There is no way in modern HTML/CSS to reproduce
> this except of using tables.
> 
> This is not exactly what you need but at least something
> that can replace table use cases. In some cases
> flex units (%%) can give even more than tables can handle.

Well, a single row is definitely NOT what I want, by *definition* of the term 
"grid" :-P

Now, h-flow seems much more in the right direction, but then, honestly, what's 
the difference between h-flow and inline-block? We're back to the same problem 
of trying to assign matching heights to every block in a row, something that is 
hacked up for us on our behalf by tables. Tables do NOT provide this (cf. 
vertical-align and height: auto) but the way tables draw borders pretends that 
all the cells are the same height for reasons of sanity.

Take away tables, and we're back at square one: no way to specify that 
successive blocks have the same height, without caring WHAT that height is. I 
don't care how tall they are (since the font size within them is a user choice 
and the text may wrap onto any number of lines) but I do care that they all match.

Your flow: horizontal example will work for a single row, because every "cell" 
element will be stretched to matching heights. This is pretty much how tables 
are visualised regardless of actual cell height. But likewise, the enforcement 
of a container element to butt containing elements against vertically, brings us 
back to enforced rows, i.e. a table.

The point I'm also making, as you may realise, is that a "fluid grid" is a 
virtual grid where as many cells fit on a row as will fit, simple as that. If 
each cell is 300 px wide, three will fit across a 1024 px wide screen, but two 
will fit across an 800 px wide screen. A table with three columns of 300px each 
will force the page wider than that 800 px wide screen (since the table will be 
at least 900 px wide) but a fluid grid will just wrap one column early.

The point is, that in most cases when it comes to galleries, no-one really cares 
how many cells fit across the window but tables (and flow: horizontal) force you 
to choose an arbitrary figure based on your ASSUMPTION of a safe screen size. 
(Even though there is no such thing)


Actually, none of this has anything to do with the subject line :P The first 
part is not related to the above at all. The second part was a realisation that 
delimited list wrapping and fluid grids are united in concept when it comes to 
decoration. After all, a fluid grid may desire such notions as row-ends, first 
row, end row and corners as regards decoration, but none of this exists in the 
HTML. A fluid grid with 25 cells is nothing more than 25 <div>s or 25 <li>s, and 
you won't know until render-time which ones are on the first and last rows, 
which are at the start and end of lines, and which are the five corners. (Don't 
forget that fluid grids have four or FIVE corners as you don't put in empty 
cells to pad out the final row like you do a table ;)

Received on Saturday, 24 February 2007 06:46:00 UTC