Re: [css3-layout] Is Template Layout just syntactic sugar?

2009/10/19 Tab Atkins Jr. <jackalmage@gmail.com>:
> On Mon, Oct 19, 2009 at 9:37 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>> In the other thread [1], starting from a syntactic addition to the
>> beloved Template Layout syntax, we slipped into a big discussion about
>> the Final CSS Layout System for Everything™.
>>
>> And I thought: we have a flexible, tabular layout system (tables), we
>> have a method to control shadow trees (binding), we have a method to
>> rearrange the formatting structure (named flows). What else is covered
>> by Template Layout, except doing it very very quickly and having an
>> awful lot of magic?
>
> Binding via XBL2 isn't implemented by anyone *yet* (though FF is in
> the middle of implementation right now), so we're still not sure how
> easy that will be to work with.  I suspect that, though it'll be
> *great* for good semantic coding in frameworks and plugins and such,
> it's way too complex for the average author to easily work with by
> hand.

I'm somehow convinced that XBL2 will be implemented before Template
Layout. About complexity, that's sure, again I'm definitely in favor
of writing "abc" "def" to get a table.

> Named flows, which certainly a darling of mine as well, have their
> problems.  I'd like to drum up some more discussion about them at some
> point, but the layout recomputation issues are significant.

Uhm... I used named flows in my examples, but XBL has @includes on
<content> that could allow the same (and anyway Template Layout had
named flows from the very beginning).

> "Doing it very quickly" shouldn't be underestimated, however.  ^_^
> Template Layout sets this stuff up *very* quickly.  The syntax sugar
> it allows is *extremely* valuable, as evidenced by the complexity of
> doing without it in your examples.  I'd like Template to be *just*
> sugar, but I still need it.

Ok, but having a template table working differently than an explicit
table is something we should avoid.

> What's magic in Template Layout currently?
>
> 1. The use of named flows at all, since that's not a first-class CSS
> notion yet.  Template sets up flows with the display property, and
> moves things into them with position.  This may turn out to be a
> decent way to move flows around.  I like position better than float,
> at least, but I prefer a new property like flow-to most of all.  My
> preferred solution would be "flow-to: slot(a)" - the flow-to property
> is later extensible for use in general named flows, and the slot()
> functional syntax indicates that it's specifically a flow created by
> Template Layout.  This is important, as multiple Templates with the
> same slot name can be nested, and elements decide where to go based on
> the nearest ancestor with a slot of that name.  General named flows
> will probably have global names.

Named Flows are magic, but they exists in GCPM 3 (but will probably be
delayed until 4).
>From an actual CSS point of view, both position is the wrong property.
"position" sets the meaning of top / left / rigth / bottom, never
changes the static position (decided by the layout manager), while
"float" chooses the flow in the float containing block this elements
should be displaced.
That is, one may model "float" such that every BFC has three flows:
left, right and middle, float chooses which one the box is lain into.
By extension, one could select any named flow in scope of the floated
element.
But actually, two elements in the same line with float:left are not
one below the other, they're one right to the other, so this only
holds in theory.
More important, every box with a "float" is a formatting context
itself, which is not needed once you actually have a block that will
get moved content and take care of layout.
So I strongly oppose "position" (including "position-flow" vs
"position-model") and mildly "float" , favoring "flow-to" as best.

> 2. The creation of ::slot pseudoelements.  This allows you to make
> containers for your flows without expressing them directly in the
> HTML.  Bindings will allow you to do the same in the future.  However,
> I'm not sure how you can make this less magic without using XBL2
> directly.  This is probably some magic we'll have to live with.

Uhm... in my example, you just needed to add @pseudo="slot(a)" to the
div representing slot "a". So it could be represented in an abstract
binding model, it's not magic.
The part about creating containers is not in ::slot, is in the way
Template Layout works. ::slot only selects the containers.

> 3. Sizing of grids based on content.  This follows the table model of
> resizable grids rather than the Grid model of static grids.  I'd like
> these two methods to be reconciled if possible, so we have only one
> concept of Grids that we build other things on top of.

Well, tables currently generate automatic grids in css3-grid, and they
follow the same model (a set of vertical / horizontal offset from the
content edge of the containing block).
The problem is you don't actually know where its possible to use grid
units (what properties, that is) and what happens if the grid is not
know at layout computation phase (for example for percentage grids, if
the width / height is not known).
One easy way to specify it would be to use grid units as another
syntax for calc(), like
a { grid-rows: 3em 20px 50%; }
b { height: 3gr; }
The height on b is then computed as calc(3em + 20px + 50%). If height
on a is auto, b gets calc(3em +  20px + auto), which is exactly
3em+20px more than the content height.
Predictable, but not what the author intended, especially if a gets a
different used height due for example to floats.
Another way to do it is to restrict grid units to absolutely
positioned elements, which can resolve percentages without problems
(for the implementation, that is).

> I don't think there's anything else, is there?

That's what I'm asking.

> ~TJ
>

Giovanni

Received on Monday, 19 October 2009 16:15:16 UTC