Re: [gradients] basics

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: 
http://msdn.microsoft.com/en-us/library/ms532997(VS.85).aspx

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

http://terrainformatica.com

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