W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: [gradients] basics

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sat, 07 Nov 2009 18:40:35 -0800
Message-ID: <4AF62FA3.9050200@terrainformatica.com>
To: Simon Fraser <smfr@me.com>
CC: www-style <www-style@w3.org>
Simon Fraser wrote:
> On Nov 7, 2009, at 3:36 pm, Andrew Fedoniouk wrote:
>> Reading this:
>> http://dev.w3.org/csswg/css3-images/#gradients-
>> The very first phrase:
>> "A gradient is a browser-generated image specified entirely in CSS, 
>> which consists of smooth fades between several colors."
>> appears as technically incorrect.
>> Common interpretation of the gradient in graphics: rule that defines 
>> color progression or distribution of colors inside some figure.
>> Filling of some image by gradient is just one of possible cases.
>> This for example:
>> http://www.terrainformatica.com/w3/ed-gradient.png
>> is an example of equidistant gradient.
>> I mean that insisting on gradient as such a "generated image" cuts many
>> useful cases upfront.
>> As I said couple of times already:
>> gradients belong to the value of 'background-color' attribute more 
>> than to 'background-image'.
> The current gradient proposals address the application of gradients to 
> CSS images. This is not to say that these are the only types of 
> gradients we would ever want in CSS; you could imagine border gradients, 
> outline gradients, and perhaps even shadow gradients. But these would be 
> separate properties, or new values for existing properties, which I 
> don't believe would conflict with the current proposal.

If to consider gradient as such a brush (which is definition of a method 
of how to fill some figure) then you can use it in many other places like:

background: linear-gradient(...);
border: linear-gradient(...);
color: linear-gradient(...); /* gradient of text */

I am not sure I understand why do we need to invent something special
each time.

> In addition, starting with gradients in CSS images is more likely to 
> result in implementations, since WebKit and Gecko already have support 
> for image gradients.

Following this argument of yours we all should go an implement filters
as IE had gradients in filters since v.5.5: 

> Also, gradients are only one kind of generated image. You could also 
> imagine solid-color images, image generators (e.g. checkerboard, perlin 
> noise etc), and generating images by applying effects to one or more 
> input images. "Generated images" are a powerful concept, so I think it 
> makes sense to start there with gradients.

These are all brushes in terms of GUI programming and graphics design.
I do not see any problems with defining something like
border: fractal-cloud(...);
background: fractal-clouds(...) url(sun.png) 50% 50%;

>> If to think that gradient is such a background-image then we need to
>> define how such an image is affected by say:
>> background-size: ....;
>> background-attachment: ... | fixed | local;
>> background-repeat: ....;
> You are correct. Gradient images have no intrinsic size, so the behavior 
> of these properties needs to be specified. At one point Gecko used 
> background-repeat as an indication that it should paint a repeating 
> gradient, but that is not in Tab's current proposal.

That is because the whole set of background-*** attributes define
image having some finite size.

I can imagine how this:

background-size: 50% 50%;
background-size: repeat; [by default]
background-image: linear-gradient(...);

could be rendered but cannot see how it is useful.
Repeating gradients define this in more useful manner.

The only attribute that define brush is background-color -
by definition it fills area defined by background-clip in full by
some solid color.

But solid color is just such a brush, precisely: solid-color(#rrggbb).

Defining background-color: #ff00ff; on element should
remove any gradient set for the element by rules with less specificity.

At least this is what people would expect.

>> And second paragraph:
>> "In many places this specification references a box, such ...."
>> definitely requires more formal specification. E.g. "would be filled
>> by an SVG image" is just sort of guess or appellation to
>> reader's intuition.
> Agreed, this could be improved.

Again: if to assume that gradient is a brush filling background in
full then all this is not required. We already know the box that needs
to be filled.

Andrew Fedoniouk.

Received on Sunday, 8 November 2009 02:41:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:30 UTC