Re: [[css3-layout]] Redundancy with table model in CSS 2?

On Fri, Nov 28, 2008 at 7:41 AM, ned haughton <> wrote:
> Hi, thanks for the excellent work on the Working Draft. It's very exciting.
> I have a few questions, and a proposal (which I offer in the interests
> of discussion), all of which are available in more detail at:
> 1. How difficult will this be to parse, and can multiple rows be parsed
> from a single line of css? ie. does display: "aa" "bc"; work?

Yes, that works.  There should be an example or two of it in the spec.
 Writing it out multi-line is purely a convenience/aesthetic issue.

> If so, how
> do the last row height and the first column height interact, especially
> if not all column widths are defined?

Row heights need a / before them, column widths do not.  This confused
me as well before I noticed this small detail.  ^_^

> 2. What happens when two rows have a different number of columns?
Any left out columns are assumed to be "." (that is, empty places in
the template).

> What
> happens when there are odd-shaped cells (ie. L-shaped, etc)?

Currently, that makes the rule invalid and the entire template
ignored.  There is a note in the spec asking about if that should be

> 3. Why display: and not a new property? An HTML table cell can be hidden
> with display:none, why make them mutually exclusive with CSS layouts?

Actually display: will be a shortcut property by the time Advanced
Layout will be implemented.  The template will be fed to the property
display-model, and display-role will be "block" (similarly,
display:none can be done with display-role: none).

> Two problems that my proposal also deals with are:
> 1. Allowing sub-child elements to be part of the layout (as far as I can
> tell, layouts cells are restricted to immediate child elements, is that
> right?)

Nope.  Whenever you give something a template position, it goes into
the nearest ancestor with a template layout.

> 2. Allowing easier modification of the layout server-side and with DOM
> modification with javascript (removing and extending elements, etc).
> It does this by naming the layout and the cell elements with the same
> name, and allowing the cell elements to define their grid references
> (top left cell and row/colspan). This means that:
> - there can be no odd-shaped elements
> - overlapping and in intrusion can work
> - sub-child elements can be used in the layout
> - very easy DOM modification
> - no new coding style (ASCII art) to learn
> and
>> two fundamental limitations: the number of rows and columns depends
>> on the mark-up if you use tables, but is fixed if you use a template;
>> and the order of the elements can be changed if you use templates,
>> but is fixed by the mark-up if you use tables.
> - number of rows/cols is not dependant on the parent element, AND order
> of elements in document is irrelevant
> Also, the markup uses a nested property, similar to background and
> background-color and -image properties.
> just a thought :)

The issue is that you're essentially duplicating the Grid Positioning
Module ( ).  In many ways Template
Layout is just a pretty face on Grid Positioning, making the whole
thing easier and more intuitive.  In fact, every alternative proposal
made in reaction to Template Layout that I've seen is just duplicating
Grid Positioning.

Advanced Layout is Bert's baby.  Can we have a reference in Template
to Grid Positioning?  Very few people know about it, especially if
they're just now being linked to Advanced Layout, and it's causing a
lot more angst and duplicated work than necessary.  (I sent an email a
bit ago talking about how to specify how Template specifies an
inherent Grid as well.)


Received on Sunday, 30 November 2008 16:14:51 UTC