W3C home > Mailing lists > Public > www-style@w3.org > October 2009

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 19 Oct 2009 11:49:55 -0500
Message-ID: <dd0fbad0910190949p79f02f86p78393f6159352bba@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: www-style@w3.org
On Mon, Oct 19, 2009 at 11:14 AM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> 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.

Yeah, it probably will be.  And yeah, we just need the sugar.

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

I need to brush up on my XBL.  It's been at least a year since I
looked at that spec.

Yeah, Template Layout has named flows, but they're still somewhat
constrained.  You know where they're going to go.  You may not know
the exact size of the template slots, but at least you won't have
weird interaction with floats or whatever.

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

I agree.  They're already so similar that making them gratuitously
different should be avoided.

> Named Flows are magic, but they exists in GCPM 3 (but will probably be
> delayed until 4).

Yeah, we'll have to see how it works with that.  They also exist in
Generated Content.

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

Ah, excellent.  I didn't know that @pseudo existed.  Like I said, it's
been a while since I've looked at XBL2.  In that case, this isn't
magic at all (it just does the shadow-tree construction for you).

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

Yes, tables produce a grid, but there's no way to create a table-like
grid *except* by creating a table.  I'm not sure what the correct
solution is, but *some* method of reliably producing a
content-flexible grid should be around.

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

Yeah, grids are complicated.

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

This is possible, but the ability to, say, have a floating element
intrude across columns and span exactly 2 columns (3gr width, to
account for the column rule area) is very compelling.  That sort of
presentation is used in print media today, and we'd like it to be
possible in a flexible manner in CSS.

>> I don't think there's anything else, is there?
> That's what I'm asking.

Well, if you're not seeing anything else, then I think we're good.
Pseudoelements aren't magic (or at least won't be once XBL2 is widely
implemented).  Named flows are magic right now, but we have other
modules that want to use them too, so we're probably going to have to
accept them.  I'd like to ensure that whatever syntax we choose is
usable by other modules too.  Finally, grid units are magic, but
that's a problem for Grid to resolve - Template's own sizing just
works like Table's sizing.

Received on Monday, 19 October 2009 16:50:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:29 UTC