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

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.

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.

"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.

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.

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.

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.

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

~TJ

Received on Monday, 19 October 2009 15:23:11 UTC