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

Re: layout idea

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 18 Mar 2009 16:05:19 -0700
Message-Id: <C44D0086-9AA0-4E63-8609-DFE6DAF5594F@gmail.com>
To: Jonathan Snook <jonathan.snook@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
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).

>
>
>> + 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.
>
> -js
>
Received on Wednesday, 18 March 2009 23:06:06 GMT

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