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

On Fri, Mar 20, 2009 at 12:54 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> 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.

Eh, not quite.  A single letter names a single slot, so all the
occurrences of a letter in the template define the slot's shape.  A
disconnected region means that a single slot is in two bits, which
isn't rectangular.

However, I acknowledge that it would probably be clearer to say that explicitly.

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

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.

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

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

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

~TJ

Received on Friday, 20 March 2009 18:03:30 UTC