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

Re: layout idea

From: David Hyatt <hyatt@apple.com>
Date: Wed, 18 Mar 2009 18:26:30 -0500
Cc: Jonathan Snook <jonathan.snook@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <871A9DD1-1B76-47C8-ACF7-21F496EE058B@apple.com>
To: Brad Kemper <brad.kemper@gmail.com>
On Mar 18, 2009, at 6:05 PM, Brad Kemper wrote:

> On Mar 18, 2009, at 10:25 AM, Jonathan Snook  
> <jonathan.snook@gmail.com> 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.
> For Web page layout, it seems like more of an edge case, with the  
> vast majority of layouts consisting of rows and columns that align  
> with each other. And if the slot can be a positioning container,  
> then it could always have a div within it to be absolutely  
> positioned (which would not usually need to be the same height as  
> the row). If the slot can be relatively positioned (assuming a  
> separate borders model), that would also allow some types of overlap.
>>> + 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).
> Agreed. Which is why I think it would me better to extend tables  
> (especially with features that would be useful to them in other  
> circumstances anyway, such as colspan and rowspan, and explicit  
> column counts to generate new anonymous table rows).

Yeah I am starting to think this is the way to go also.  For example:

div {
   display: table;
   table-rows: 5 / 1em * 3* 20px 4em;
   table-columns: 5 / 20px;  /* Pattern could repeat */

You could envision properties like the ones above to go ahead and  
create a certain number of anonymous rows and columns, and perhaps a  
"/" addition for specifying some explicit column widths (supporting  
the same * notation usable in HTML tables for flexing).

For spans:

.myCell {
   table-row-span: 2;
   table-column-span: 3;

Pseudo-elements on the object acting as the table could address the  
anonymous rows, columns and cells.

   vertical-align: top;

A functional notation could address specific rows or cells:


::table-cell(1, 1)

For source-order independence, you could use a new property to place  
an object inside one of the anonymous cells.

#myContent {
   table-position: cell(1, 2);

Absolute positioning when the table is the containing block could  
support rows and cols units to also allow out of flow positioned  
objects to align with specific cells.

#myPositionedObject {
   position: absolute;
   left: 3rows;
   top: 5cols;

I admittedly haven't put a lot of thought into this, but at first  
glance I don't see anything that would preclude tables from being able  
to support many of the requirements raised by these other proposals.

Received on Wednesday, 18 March 2009 23:27:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:25 UTC