Re: layout idea

On Mar 18, 2009, at 6:05 PM, Brad Kemper wrote:

> On Mar 18, 2009, at 10:25 AM, 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.
> 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