Re: layout idea

On Mar 18, 2009, at 12:25 PM, Jonathan Snook wrote:

>
> On 16-Mar-09, at 4:01 PM, Bert Bos wrote:
>> + accidentally overlapping slots is impossible
>
> I don't think we can ever stop people from making mistakes and being  
> able to overlap slots is, to me, a handy feature.
>
>> + what is the height and width of slots (your syntax allows multiple
>>   conflicting widths and heights, even impossible ones)
>
> This is the case with tables, as well, which is something I tried to  
> mimic as I felt it'd be easier for people to grasp (at least for  
> those who've done table-based layouts) and easier for implementors  
> (since this logic is already in place for tables).
>
>> + self-documenting: the "ASCII art" serves as a diagram of the
>>   intended layout (some people do not like this, not sure why)
>
> The biggest dilemma with this is just spaces vs tabs and trying to  
> maintain "ASCII art". (Somehow I see bloggers dedicating whole  
> articles just on best practices for this.)
>
> My reason for putting together Matrix Layout was not because I felt  
> it was a better implementation that solved all problems but because  
> it was a simple implementation based heavily on existing concepts  
> that would make it easier for implementors to build sooner rather  
> than later. Dave Hyatt's recommendation of extending the Grid Module  
> has made increasing sense to me and I have no major complaints with  
> that solution, either.

I was pointed to:

http://meyerweb.com/eric/thoughts/2009/02/17/wanted-layout-system/

I agree with most of what Eric says, although I believe he may be  
condemning table layout too quickly (after all, table layout could be  
extended dramatically).

Here are my high-level thoughts about a better layout system:

(1) We really need to pick a single proposal and run with it.  Right  
now we have table layout, Template Positioning, Grid Layout, Matrix  
Layout, Andrew's grid flow, and - although it hasn't been written up  
yet - the XUL flexbox grid.  These layout systems all define objects  
with rows and columns and spanning cells.  Some of them have more  
capabilities than others, etc., but they're all really similar.  The  
question we have to ask is: which one do we use?

(2) A grid should be a normal flow construct.  Positioning objects  
that snap to a particular row/column position while still being out of  
flow and not affecting the layout of the grid itself should be possible.

(3) Spans should be supported on cells in the grid.

(4) It should be possible to put objects in slots in the grid and have  
them be part of the grid's flow (i.e., not positioned out of flow).   
This could be done by saying the object itself *is* the cell, or by  
saying the object goes *into* a cell.  "Source order independence."

I think it would be a worthwhile exercise to examine whether or not  
table layout itself could be extended to have all of these features.   
I know Eric Meyer was quick to condemn it, but I believe he's thinking  
of table layout as it works today.  Let's imagine we could extend it:

(a) Add row-span and column-span to CSS.  This is trivial to define  
and to implement.  We can make it so that cells can have spans when  
defined in CSS.
(b) Add row-position and column-position to CSS.  I see no reason why  
this should not be possible.  We'd have to figure out if it was table  
section relative or whole-table relative.  I'd say probably the  
former.  It would probably be easiest for this to apply to objects  
with display: table-cell only, but you could also imagine creating an  
anonymous table cell at that position if none existed yet.
(c) Add table row/column units to left/top for positioning objects  
relative to a specific cell.
(d) If table layout has some limitations (for example vertical flexing  
like XUL grids can do), that could always be solved with a new value  
of the table-layout property.

I guess I'm wondering if anyone has given much thought to extending  
table layout to *be* a grid system like this, and if there are any  
obvious problems with such an idea.  To me it looks completely  
possible, and also has the advantage of building on existing  
implementations in every modern browser.

dave
(hyatt@apple.com)

Received on Wednesday, 18 March 2009 18:39:49 UTC