W3C home > Mailing lists > Public > www-style@w3.org > December 2007

Re: [css3-multicol] [css3-grid] and other layout managers

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 14 Dec 2007 19:45:45 -0800
Message-ID: <47634DE9.8050904@terrainformatica.com>
To: Christoph Päper <christoph.paeper@crissov.de>
CC: WWW Style <www-style@w3.org>

Christoph Päper wrote:
> Andrew Fedoniouk:
>> De facto multicol[1] and grid[2] introduce different layout managers.
>> 1) These layout schemas use their own subsets of attributes - not a 
>> single attribute but a number of dependent attributes.
>> 2) These attribute subsets are independent by nature so if one schema 
>> is applied then secondary attributes - remnants from previous
>> schema shall be discarded as a whole;
> I'm following you through here, but the syntax you propose just looks 
> wrong and is unlikely compatible to CSS grammar.

Yes, it is incompatible but is it look wrong?

>> #eid
>> {
>>    layout:  columns
>>        {   count: 3;
>>            width: 45px;
>>            gap: 0;
>>            rule: none;
>>        }
>> }
>   #eid {
>     layout: columns;     /* ain't it LtRTtB-centristic? */
>     columns: 3;          /* now |column-count| */
>     rows:    3;          /* ignored */
>     column-width: 45px;
>     column-gap: 0;
>     column-rule: none;
>   }
>   #eid {
>     layout: grid;
>     columns: 3;          /* or |column-count| */
>     rows:    3;
>     column-width: 45px;  /* probably ignored */
>     column-gap: 0;       /* perhaps ignored */
>     column-rule: none;   /* perhaps ignored */
>   }

That is exactly the problem.

If, say, column-gap is used in both: grid and columns then you cannot r 
rely on default values of attributes anymore - you *must* redefine
all attributes. That is somehow conflicting with idea of cascading and 

As deeper in the forest as more wolves around: we are getting more and 
more compound function alike values of properties. Think about  that 
gradients as an example. I believe that the gradient() function proposal 
is also an example of need of "structural attributes". Function notation 
is bad as it does not support named arguments.

Technically flat notation
     column-count: 3;
     column-width: 45px;
     column-gap: 0;
     column-rule: none;

is equivalent to

     layout: columns
        count: 3;
        width: 45px;
        gap: 0;
        rule: none;

in terms of internal representation of attributes in UAs - so no need to 
change implementations dramatically.

Benefits of structural attributes are:
1) they create local name spaces so future side effect free expansion is 
2) conglomerates of attributes are applied in all or nothing manner so 
cascading of values of attributes like the layout above is by itself 
also free from side effects:

    layout: default;

will discard the whole bunch of attributes.

More on this gradient thing...


    background-color: #DDD;
    background: gradient-radial
       position: 50% 50%;
       stops: 0%/#CCC 100%/#FFF;

  and later you may redefine it completely as:

    background: gradient-linear
       start: 0% 0%;
       start: 100% 100%;
       stops: 0%/#CCC 100%/#FFF;

but if you will want later to render it with just an image then you can 
do it as:

    background: image-repeat
       src: url(...);
       position: 50% 50%;

Think about this: we almost near to have five different background 
drawing methods: nothing(transparent background), solid color, gradient, 
image(that has 5 or so sub methods) and the border-image thing.

At least last three conflict with each other.
Say you have gradient and image defined for the same element. Whichever 
wins? They have to be mutually exclusive.
Otherwise redefining solid background color for some element requires 
explicit disabling of all other background attributes like images and 
gradients. Imagine now that in future we will want one more background 
method, say, background-fractal-cloud. This will require one more item 
to be disabled explicitly while cascading. That is not user and future 
friendly and very far from being modular.

Andrew Fedoniouk.

Received on Saturday, 15 December 2007 03:48:06 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:24 UTC