Re: Template Layout, implementation, some comments. Was: Re: layout idea

On Fri, Mar 20, 2009 at 1:52 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> Tab Atkins Jr. wrote:
>>
>> On Fri, Mar 20, 2009 at 12:54 PM, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>
>>
>>>
>>> If we have say this:
>>>
>>>  flow: "a b"
>>>      "a b";
>>>
>>> And two elements with the same value of float: "a"; so they compete for
>>> the
>>> same spot in the template.
>>> What will happen in this case? Current spec again assumes creation of
>>> artificial containers.
>>>
>>
>> Indeed, it does use artificial containers, because these are very
>> useful.  It lets us group multiple things together into a single area
>> without having to wrap them explicitly in our HTML.  This, in turn,
>> gives us *much* greater flexibility in layout, which is extremely
>> useful.
>>
>>
>
> Artificial containers are so flexible that no one clearly understands when
> and how they are created.
> What if you have:
> #some-child { display:table-cell; };
> that will be placed inside that templated container. How many those elements
> need to be created around?

Within Template Layout?  The whole shebang.  The anonymous container
created by template layout isn't a table-cell, so #some-child will
wrap itself completely in a table.

There is an ambiguity regarding just *when* table-wrapping occurs.
Frex, you could have two adjacent elements in the source which are
both display:table-cell.  Normally, they would both be wrapped into a
single table.  But if they were moved into separate template slots,
they shouldn't do so.  This does indeed need to be cleared up, and I
believe it can be done so fairly simply by specifying that flowing
occurs before table-wrapping.

> These artificial things look good only on initial paper.  The final spec
> that is written *after* any practical
> implementation will become so non-comprehensible that you may forget about
> its flexibility - to many if's
> and else's.

I disagree currently, though I'm open to being proved wrong.

>>> And yet it uses 'display-role' that was gone long time ago.
>>>
>>
>> Eh, display-role is basically the same thing as your 'flow' property.
>> However, I don't see what relevance this has to the question of
>> artificial containers.
>>
>>
>
> The 'flow' is close to 'display-model' rather than to 'display-role'.
>
> 'display-role' as it is defined here:
> http://www.w3.org/TR/2002/WD-css3-box-20021024/
> is more like 'display'.

Ah, thank you, I had never been able to find the original reference,
and was inferring what those properties originally meant.

> And 'display-model' is what that artificial containers lack.
> As they have no selectors then it is not clear what model are they using.
> block-inside, inline-inside or what?

It's pretty clear, I think, that block-inside is intended.  The
anonymous blocks are, well, *blocks*, and that's the most reasonable
default.

> To solve this you would need some pseudo-element selectors. That
> would be never-ending story. E.g. display: table-cell will need :owner-row
> or some such.

Hmm?  I'm confused as to what this statement means in context.

>>>
>>> I propose to drop that multiple-elements-in-single-slot feature
>>> completely.
>>> Instead to use first-in-first-serve rule.
>>> That will simplify significantly the whole mechanism - you do not need to
>>> define dimensional metrics of rows/columns -
>>> standard width/height/margin of elements can be used for defining their
>>> metrics. In proposed spec two systems of
>>> dimensional constraints compete for computed values of the same elements.
>>> Not good at all.
>>>
>>
>> Can you elaborate here?  What are the two systems that compete?  Is
>> the situation any worse than what currently exists for tables, which
>> turns out to actually be pretty useful?
>>
>
> Say you have:
>
> flow: "a" 200px
>       "b" 300px;
>
> and
>
> #a { float:"a"; width:100px; }
> #b { float:"b"; width:400px; }
>
> What would be dimensions of these elements at the end? Two systems of length
> attributes : one in template and another
> one is defined by the elements themselves.

Well, an explicit width for the slots isn't given in the template, so
the width will be whatever the containing block's width is.

Maybe you meant to give a height for #a and #b?  In that case, #a is a
100px high in a 200px slot.  #b is 400px high in a 300px slot.  #b
will overflow its slot, with the exact effects of this given by the
overflow property set on ::slot(b).

>>>> Flex units are already in the template spec.  They use * as the unit.
>>>> (They are also in the Grid Positioning spec.)
>>>>
>>>>
>>>
>>> These are not units in common sense. E.g. flex *units* are useful in
>>> other
>>> layout schema's. Think about
>>> display:table/table-cell. Without flexes that display:table and friends
>>> have
>>> little sense if to compare this feature with
>>> the <table>.
>>>
>>
>> Oh, certainly, it would be much better to have a CSS-wide defined
>> notion of a flex unit.  But for now, flexes *do* exist in the Template
>> module, so you can't really complain about the lack of them in that
>> module.
>>
>
> Flex unit defines *weight* in distribution of spaces. So it is some number
> with the unit designator:
> 1*, 2*,  0.5*, etc. And here they are.... I don't know what... let's name
> them placeholder designators or so.

Yes, this is true.  This is how they are used within the template
module, too - a bare * is just a shorthand for 1*, and you can specify
2*, 3*, or whatever.  I'm not sure what you're objecting to.

~TJ

Received on Friday, 20 March 2009 19:28:31 UTC