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

2009/10/19 Tab Atkins Jr. <jackalmage@gmail.com>:
> 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.

Good to see we agree.

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

Uhm... I'm not sure. I mean, it's not that you can infer much on the
position and size of flowed boxes, based only the template, because
that in turn depends on a variety of factors.
OTOH, you still have issues with counters and containing blocks for example.

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

Good to see we agree.

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

But Generated Content is not going be updated for a while, I guess.

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

Uhm... I'm not sure this can be solved anyway, except with Template Layout.
The current Grid approach requires having a used width / height.

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

It would be possible, if the column width does not depend on the
float's width, which is true unless the column width depends on
content (for example a floated multicol).

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

Fantastic

> ~TJ
>

Giovanni

Received on Monday, 19 October 2009 18:09:21 UTC