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

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

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?

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

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 20 March 2009 18:53:36 UTC