What would your preferred way of going about it be?

Note, though, that your newly reduced proposal can be generalized quite a bit for much greater usefulness.

First, realize that all Grid actually does is set up a custom context-sensitive length unit and then specify where it can be used. This is why Grid is so easy – it can interact with all the existing properties because it lives on a completely orthogonal level, that of the unit rather than of the property.

So, when you say you want the ability to name grid ancestors, what you’re really saying is that you want to be able to specify positioning ancestors. Wanna work on a proposal together? ^_^

Thanks for your response Xanthir, very educational. I had a feeling that I should sit on this for a few days after I wrote it, but I guess I got over excited. I’ll have a read of the grid spec, it sounds good.

Nope, follow the link I provided. You’re talking about CSS Tables, I’m talking about CSS Grid Positioning. Completely different things.

In Grid Positioning, you give an element a grid with the grid-rows and grid-columns properties. You can specify row widths and column heights with any of the CSS length units, plus flex units (units that distribute remaining width between themselves proportionally. Then you use the normal position: and width:/height: properties with the gr unit (for “grid unit”, corresponding to the context-sensitive width or height of a grid row/column, and determining the context is a little complex but generally does what you’d expect) as appropriate.

Duplicating the template layout you use for comparison would be something like (I’m going off the top of my head, so consider this pseudocode):
body {
grid-rows: 5cm .25cm 5* 2* 3*;
grid-columns: * 3em 2* 3em 3em 2* 3em;
position: relative; //to establish this as a positioned ancestor
}

h1 {
height: 1gr;
}

#toc {
position: absolute;
left: 0;
top: 2gr;
width: 1gr;
height: 3gr;
}

#leader {
position: absolute;
left: 2gr;
top: 2gr;
height: 1gr;
width: 5gr;
}

#art1 {
position: absolute;
left: 2gr;
top: 3gr;
height: 1gr;
width: 5gr;
}

#art2 {
position: absolute;
left: 2gr;
top: 4gr;
height: 1gr;
width: 2gr;
}

#art3 {
position: absolute;
left: 5gr;
top: 4gr;
height: 1gr;
width: 2gr;
}

Note that in my email to the list a week back or so about the template layout, I proposed adopting a proper flex unit, so your example could be simplified quite a bit more to:
body {
display:
“aaaaaaa” /5cm
“…….” /.25cm
“b.ccccc” /5*
“b.ddddd” /2*
“b.ee.ff” /3*
* 3em 2* 3em 3em 2* 3em;
}

(Though you’d probably want to replace the last two row-heights with “intrinsic”, since you’re putting pictures in there which may have varying heights.)

There is still a slight limit in Grid Positioning that doesn’t exist in your proposal, namely that you can only position based on the nearest positioned ancestor, but this is the same limitation that exists in normal CSS positioning. (Note that you can still use gr units without positioning if you want, and they’ll instead inherit from the nearest grid ancestor, which may be different from the nearest *positioned* grid ancestor.)

And don’t worry about butting in. Advanced Layout hasn’t moved in years. Designer response is the surest way to get something worked on. ^_^

Re: CSS3 grids: I know about them, I mentioned them in the first paragraph. The main problem with CSS Grids is that there grid cells have to be in the correct order in the HTML. This proposal doesn’t require that: due to the “name” value of the template property. Also, this proposal allows intrusion (described in the advanced layouts WD), which CSS Grids doesn’t.

I fully realise that my butting into a w3c process that’s already many years old is a bit impudent, so thanks for the positive response

Essentially you’re reinventing the wheel – what you describe is merely a rewriting of the CSS3 Grid Positioning Module ( http://www.w3.org/TR/css3-grid/ ). Don’t worry, though, basically every proposal made in response to Template Layout that I’ve seen is of this form, so you’re not alone. ^_^

The WG needs to put a reference into Template referring to Grid Positioning, since Grid is basically Template’s big brother. Template is extremely easy to use while authoring and easy to visually get an idea of how the page is laid out. Grid how more power, but isn’t quite as intuitive. The two together are a good mix I think.

Also, in response to your last comment, display *will* be split into two properties, display-role and display-model, with pretty much the distinction you are making. The display property by itself will then be a shortcut property, like margin is for margin-left, margin-top, etc.

Finally, that quote you use from Ben Ward’s blog is EXTREMELY dishonest. It’s used completely out of context, which is disgusting. The full sentence you grabbed the quote from is “Sounds a bit hacky, perhaps even silly but I think it’s a good move; it’ll be very easy to explain and grasp.” You directly imply that the Ben Ward disapproves of Template Layout, and rely on the reader to correct that misapprehension themselves. You need to either take out that reference altogether, or put in a parenthetical note that Ben still believes Template Layout to be a good idea.

No, not setting the width/height wouldn’t over come it in all cases, ie:
“a a a a”
“b c c c”
“b c c c”
“d e e e”
If you simply want to remove “d”, and extend either “b” or “e” to that position, the template won’t let you, because of the existing dimensions of the other element.

The funny shapes thing is plausible, but element shape isn’t mentioned in the spec at all. If you were going to do something like this, why limit yourself to weird tetris shapes? Why not just use something like SVG? It’s almost certainly going to be implemented widely before this CSS3 module is…

I guess that’s true about the display property. If the element needs to stay there but be invisible, there’s visibility: hidden. The display property just feels huge an convoluted. There are almost two distinct sets of values within it:
Single-element display values, like “run-in”, “block” and “inline”
Multiple-element values, like “table”, and then the new template system, designed for layout
and “none”, which is unique, and “marker”, which is also.
Perhaps just splitting the second group of into a similarly generic layout property?

I can’t see how the working draft causes the “sub-child” (should this be just “child”, “sub” seems superfluous?) limitation. The examples use children as the cells, but this just seems to be because they’re comparing it with the table model, which does require parent>child relationships in the markup.

Yes, it would be annoying to have to define a layout for each page element combination (and having to rely on the markup to specify which combination it was would be even more annoying). Perhaps this can be overcome by not setting dimensions for empty rows/columns and specifying dimensions directly on the elements that are to appear in the table (and then rows/columns with no or hidden elements would shrink to zero)?

Funny shaped areas: perhaps this is intentional? Perhaps the elements placed in the funny shape are intended to flow into the space (the way elements do around conventional left or right floated elements)? Perhaps the neatest way for this to be described is to use the grid format in the working draft?

I think use of the display and position properties is appropriate (or appropriate enough). Like you say, the “none”, “table” and proposed template values are all mutually exclusive (we don’t care whether it used to be a table or template layout if it’s being hidden). Actually, I retract that: when using JS to dynamically hide elements, one would have to store the current “display” value before setting it to “none”, and reinstate when unhiding the element. Not a big issue, but a bit Boring.