W3C home > Mailing lists > Public > www-style@w3.org > March 2009

Re: layout idea

From: David Hyatt <hyatt@apple.com>
Date: Thu, 19 Mar 2009 14:28:21 -0500
Cc: Jonathan Snook <jonathan.snook@gmail.com>, www-style@w3.org
Message-id: <CEC4E776-53F5-4B7A-AFB8-070463451F41@apple.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Yes, I completely agree that tables would need to be enhanced to  
better support flexing.  I think the first step is still to just  
figure out if the other problems (source order independence, arbitrary  
positioning, using tables at all to do this) are solvable first... as  
enhancing the layout of tables to support flexing is actually one of  
the easier problems to solve here. :)

dave

On Mar 18, 2009, at 11:14 PM, Andrew Fedoniouk wrote:

> David Hyatt wrote:
>> 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)
>
> Dave, I guess that table layout here is display:table and friends.
>
> Adding of just @col-span and @row-span to CSS is far not enough.
>
> To be able to reproduce <table>s in full CSS should have:
> 1) flex units, that is a must.
> 2) overflow:never[ or none]; or min-width:min-content-width / min- 
> intrinsic, same for height.
>
> Without these <table> is non-beatable by CSS for layout purposes.
>
> While consider various options we should keep in mind that there
> are and will be other useful layout schema's other than the grid.
> So I think it has to be @flow attribute or something that allow to  
> define layout manager.
>
> So far I have these LMs:
>  flow:horizontal - all elements replaced in single row with
>       vertical flexes computed against row height. So you can
>       define that all elements will have same height equal to
>       tallest element in the row. Horizontal flexes computed
>       against width of the container.
>  flow:horizontal-flow - pretty much the same as above but
>       elements are being replaced in multiple rows. Existing
>       @clear allows to break rows explicitly. Think about bricks
>       in the wall, that is it.
>  flow:vertical-flow - like above but elements replaced in
>       multiple columns.
>  flow:vertical - that is pretty much what <div> is using now for
>       layout of its child blocks.
>  flow:grid - that is what I was talking about before.
>
> So as you can see grid/table layout is just one of many layout
> managers[1]. I think it would be wise to dedicate special attribute
> to it.
>
> And yet about table layout and col/row-spans.
> <table>s have simple but limited algorithm of calculating constraints
> that spanned cells apply to spanned rows/columns. That algorithm  
> probably needs to be revised. But in any case, even for display:table
> existence of flex units[2] is crucial.
>
> And I am yet silent about flex usefulness in animations. Here is an  
> example: http://terrainformatica.com/htmlayout/images/animation-slide-bar.jpg
> Expanded section there has height:100%%; spanning all available  
> vertical space in the container. So expanding/collapsing animations  
> are trivial - from 0%% to 100%% on expanding and from 100%% to 0%%  
> on collapsing.
>
>
> [1] http://java.sun.com/docs/books/tutorial/uiswing/layout/visual.html
> [2] http://www.terrainformatica.com/htmlayout/fspu.whtm
>
>
> -- 
> Andrew Fedoniouk.
>
> http://terrainformatica.com
Received on Thursday, 19 March 2009 19:29:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:17 GMT