- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 30 Nov 2008 10:14:15 -0600
- To: "ned haughton" <naught101@gmail.com>
- Cc: www-style@w3.org
On Fri, Nov 28, 2008 at 7:41 AM, ned haughton <naught101@gmail.com> 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: > http://eco101.wordpress.com/2008/11/28/css3-advanced-layout-module-templates/ > > 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 changed. > 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. > http://eco101.wordpress.com/2008/11/28/css3-advanced-layout-module-templates/#definition > > just a thought :) The issue is that you're essentially duplicating the Grid Positioning Module ( http://www.w3.org/TR/css3-grid/ ). 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.) ~TJ
Received on Sunday, 30 November 2008 16:14:51 UTC