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

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
#eid
{
     column-count: 3;
     column-width: 45px;
     column-gap: 0;
     column-rule: none;
}

is equivalent to

#eid
{
     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 
possible;
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:

  #eid
  {
    layout: default;
  }

will discard the whole bunch of attributes.

More on this gradient thing...

Example:

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

  and later you may redefine it completely as:

  #eid
  {
    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:

  #eid
  {
    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.

http://terrainformatica.com
Received on Saturday, 15 December 2007 03:48:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:56 GMT