Re: [gradients] basics

Tab Atkins Jr. wrote:
> On Mon, Nov 9, 2009 at 11:40 AM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> Say you have following:
>>
>> // file common.css
>> body { background: linear-gradient() }
>>
>> // file A.css
>> body { background: url(a.png) repeat }
>>
>> // or file B.css
>> body { background: url(b.png) repeat }
>>
>> The task is to be able to keep in
>> A.css all other background settings defined in common.css
> 
> That is a much more general problem that afflicts *any* CSS properties
> that take more than a single value.  It just happens to be even worse
> for properties that take a list of values, but it's nothing special
> about backgrounds and gradients.  "common.css" could define another
> image which you want on a particular level.  Or it could be shadows,
> or fonts, etc..

There are no other CSS properties that take multiple values and
cannot be split into separate parts. For example:

background-position: x y;

can easily be declared as a shortcut form of two:

background-position-vertical:y;
background-position-horizontal:x;

But infinite list of backgrounds cannot be split this way.
Background lists create precedent of let's say
reducing quality of cascading in CSS.

The gradient-as-an-image makes this problem even worse.
Gradient is going to be quite popular feature and when accepted it
will make that CSS design flaw shine/shame forever.

If these multiple backgrounds are really needed (I would like to
see examples when they are useful) then solution could be in making
background attributes to accept named layers:

background: url(1.jpg) as fore, url(2.jpg) as back;

So later you will be able to redefine particular components as

background[fore]: url(3.jpg) no-repeat;
background[back]: url(4.jpg) repeat;

or as

background.fore: url(3.jpg) no-repeat;
background.back: url(4.jpg) repeat;

or

background/fore: url(3.jpg) no-repeat;
background/back: url(4.jpg) repeat;

But that is, indeed, not a problem of gradients per se.

As I said if gradient will be such a color then
we probably do not need background lists at all -
color layer and image layer will be independently addressable.

If someone really see the value of multiple images then
it is always an option to introduce something like list() function that
will accept the same comma separated list of image (and only, no color) 
definitions.

background: list( fore: url(1.jpg) no-repeat,
                   back: url(2.jpg) repeat ) red;

But in most multi-image cases it is enough to have expandable images
like: http://www.terrainformatica.com/wiki/h-smile/expandable-backgrounds

IMHO.


> 
> (This is why I'm not happy with how properties that take lists work at
> the moment, but we won't solve this issue by special-casing every
> individual problem as it happens.)
> 
> ~TJ
> 


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 10 November 2009 03:53:59 UTC