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

Tab Atkins Jr. wrote:
> On Fri, Mar 20, 2009 at 12:14 AM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>   
>> The most non-trivial part was implementation of parsing of the template.
>> Not parsing per se but handling of border cases. Say, it is not clear what
>> this means:
>>   flow: "a a"
>>         "b c"
>>         "d a";  ?
>> "a" area is not continuous here. Error handling should be clearly defined by
>> the specification.
>> I propose for now to declare that each named area shall be a)
>> of rectangular shape and b) unique and so continuous.
>>     
>
> The spec already says that areas must be rectangular.  Two separated
> regions do not make a rectangular shape.  Thus the rule is invalid.
>   
It just says "Non-rectangular slots are illegal" [1].  But it is silent 
about multiple rectangular regions.
Thus "unique" must be there for the completeness.
>   
>> I propose to drop '@' feature completely, instead to declare following:
>> All immediate children of the container-template that have no float:"XX"
>> defined are replaced as they occupy single row that is appended to the main
>> grid. Easy to implement and quite predictable.
>>     
>
> That sounds like an excellent rule for what to do when there *isn't*
> an @ in the template, but that's no reason to drop @ entirely.  The @
> made pushing "everything else" into a slot very easy.  Without it you
> have to use a properly scoped * selector, and make sure that all your
> other positioning rules have selectors with enough specificity to
> override it.
>   
'@' implies creation of artificial container for multiple elements. That 
container requires pseudo-element
selector to deal with. Practice ( display:table et al ) shows that such 
artificial containers are very hard to deal with - they
clash with other CSS features in various hard to predict ways. 
Artificial containers should be avoided as much as possible.

'@' problem is close to this one:

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.
And yet it uses 'display-role' that was gone long time ago.

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.
>   
>> And I'd like to note again that flex units are highly desirable in such
>> cases.
>>     
>
> 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>.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 20 March 2009 18:02:57 UTC