|
[gradients] basics
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.pngis 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'.
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: ...;
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.
--
Andrew Fedoniouk.
http://terrainformatica.com
|
|
Re: [gradients] basics
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.pngis 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.
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.
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.
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. 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.
Simon
|
|
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
|
|
Re: [gradients] basics
On Sat, Nov 7, 2009 at 5:41 PM, Simon Fraser < smfr@...> wrote:
> 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.
Indeed. There is no reason to assume that we'll never address the use
of generalized brushes in CSS, but that does *not* mean that the color
property is the best place to do so. It isn't. Colors are
intrinsically simpler than images - they have no dimension or
direction. Gradients have both, because they're images.
>> 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.
I don't understand how this is unclear. If these properties have
undefined interactions with images lacking intrinsic sizes, then the
problem lies in CSS2.1. It is not appropriate to define that
treatment here.
>> 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, I don't know how this is unclear, or how it relies on any sort
of intuition. CSS2.1 is clear about how to size an image without
intrinsic dimensions; if it's not, the definition needs to be fixed
*there*. File a bug on it if you feel it is underdefined.
~TJ
|
|
Re: [gradients] basics
On Nov 8, 2009, at 6:54 am, Tab Atkins Jr. wrote:
> On Sat, Nov 7, 2009 at 5:41 PM, Simon Fraser < smfr@...> wrote:
>> 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.
>
> Indeed. There is no reason to assume that we'll never address the use
> of generalized brushes in CSS, but that does *not* mean that the color
> property is the best place to do so. It isn't. Colors are
> intrinsically simpler than images - they have no dimension or
> direction. Gradients have both, because they're images.
>
>>> 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.
>
> I don't understand how this is unclear. If these properties have
> undefined interactions with images lacking intrinsic sizes, then the
> problem lies in CSS2.1. It is not appropriate to define that
> treatment here.
I see that < http://www.w3.org/TR/css3-background/#the-background-size>
etc. describe behavior when lacking intrinsic size. I stand corrected.
Making gradients always have no intrinsic size does prevent one
possible effect an author may desire: generating a gradient image of a
particular size, and then having that tiled over the background.
>>> 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, I don't know how this is unclear, or how it relies on any sort
> of intuition. CSS2.1 is clear about how to size an image without
> intrinsic dimensions; if it's not, the definition needs to be fixed
> *there*. File a bug on it if you feel it is underdefined.
The text is:
> In many places this specification references a box, such as "the
> box's top-left corner" or "the box's right side". In all of these
> circumstances, the box refers to the rectangle that would be filled
> by an SVG image without intrinsic dimensions used in the same
> context. See the CSS 2.1 spec for clarification on this.
I think the points made need to be:
* gradient images have no intrinsic size,
* therefore they fill the box they are being rendered into (like SVG
images with no intrinsic size)
* and therefore, when applied to backrounds, background-size etc have
no effect.
If you refer to the CSS 2.1 spec I think you should be more specific
about which section you are referencing.
Simon
|
|
Re: [gradients] basics
Tab Atkins Jr. wrote:
> On Sat, Nov 7, 2009 at 5:41 PM, Simon Fraser < smfr@...> wrote:
>> 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.
>
> Indeed. There is no reason to assume that we'll never address the use
> of generalized brushes in CSS, but that does *not* mean that the color
> property is the best place to do so. It isn't. Colors are
> intrinsically simpler than images - they have no dimension or
> direction. Gradients have both, because they're images.
*A color* as a concept has no dimension, yes.
But we are speaking here about the 'background-color' which, as
its name stands, defines [distribution of] color inside
background box.
The same apply to other color attributes in CSS they always have
"dimensions".
And on "There is no reason to assume that we'll never address the use
of generalized brushes in CSS".
Why not to think a bit upfront now?
---
In any case I think that these two lines:
background: linear-gradient(magenta yellow) url(...)
background: url(...) linear-gradient(magenta yellow)
shall produce the same result. In the same way as:
background: magenta url(...)
background: url(...) magenta
--
Andrew Fedoniouk.
http://terrainformatica.com
|
|
Re: [gradients] basics
On Nov 8, 2009, at 8:50 AM, Simon Fraser wrote:
>>> 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.
>>
>> I don't understand how this is unclear. If these properties have
>> undefined interactions with images lacking intrinsic sizes, then the
>> problem lies in CSS2.1. It is not appropriate to define that
>> treatment here.
>
> I see that < http://www.w3.org/TR/css3-background/#the-background-
> size> etc. describe behavior when lacking intrinsic size. I stand
> corrected.
>
> Making gradients always have no intrinsic size does prevent one
> possible effect an author may desire: generating a gradient image of
> a particular size, and then having that tiled over the background.
Right. I think this is a fairly essential assumption of the proposal,
and not one that I would change either. Because there is no intrinsic
size or aspect ratio, the default interaction with 'background-image'
is that the gradient is scaled to the dimensions of the background
positioning area.
If you actually want the gradient scaled to some other dimensions, you
can use 'background-size' to do so. Then you can use 'background-
repeat' to tile the gradient. Which is why you don't need the gradient
function itself to have a way to repeat the gradient inside itself.
Any UA that supports 'background-repeat', 'background-size', and Tab's
'linear-gradient()' should support tiling a properly sized gradient
with 'background-repeat'. What Gecko does that goes beyond this is to
adjust the tiling so that the gradients in each tile line up with each
other. Thus, if you had a 30deg gradient, the tiles of 'background-
repeat' are not in rows and columns as they normally are, but
presumably shift each column (or row?) so that the colors of the
gradient in each tile will line up with its neighbor. Although, that
doesn't precisely describe how something like 'repeat-x' would work
with a gradient that includes, say, a 10deg gradient or even a top-
left to lower-right gradient.
That is kind of nice behavior, even though it seems like a somewhat
uncommon need. Perhaps we could eventually add a note to 'background-
repeat' to explain how to tile generated images like gradients that
can have a more seamless joining of tiles as with Gecko.
|
|
Re: [gradients] basics
On Nov 8, 2009, at 10:43 AM, Andrew Fedoniouk wrote: background: linear-gradient(magenta yellow) url(...)
background: url(...) linear-gradient(magenta yellow)
With the current draft, these would be treated as multiple background images, with the last one in the list on the bottom. So, no, they are not the same thing. But there are certainly reasons to be able to layer 2 gradients, or a gradient on top of another image:
- When layering 2 gradients with transparency on the top one (at least), you can get more complex gradients that blend colors in two or more directions at once.
- When layering a gradient over some other non-repeating background-image (a large logo, for instance), you can create a fade-out effect for that image, by blending from a color (matching the background-color) to transparent.
- Similarly, you can create the effect that a normal patterned background is fading out as it gets closer to one edge, by putting a full-width/height linear-gradient over it that fades from a color to transparent.
It seems to me that we've already discussed these arguments at length in previous threads, and the working group resolved to continue with the concept of gradient-as-image. Let's work on that first, and resolve any issues with it before tackling a wider application of the concept to anything-with-a-color-can-have-a-gradient-instead.
|
|
Re: [gradients] basics
On Nov 8, 2009, at 11:37 am, Brad Kemper wrote:
> On Nov 8, 2009, at 8:50 AM, Simon Fraser wrote:
>
>>>> 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.
>>>
>>> I don't understand how this is unclear. If these properties have
>>> undefined interactions with images lacking intrinsic sizes, then the
>>> problem lies in CSS2.1. It is not appropriate to define that
>>> treatment here.
>>
>> I see that < http://www.w3.org/TR/css3-background/#the-background-
>> size> etc. describe behavior when lacking intrinsic size. I stand
>> corrected.
>>
>> Making gradients always have no intrinsic size does prevent one
>> possible effect an author may desire: generating a gradient image
>> of a particular size, and then having that tiled over the background.
>
> Right. I think this is a fairly essential assumption of the
> proposal, and not one that I would change either. Because there is
> no intrinsic size or aspect ratio, the default interaction with
> 'background-image' is that the gradient is scaled to the dimensions
> of the background positioning area.
>
> If you actually want the gradient scaled to some other dimensions,
> you can use 'background-size' to do so. Then you can use 'background-
> repeat' to tile the gradient.
You're right, so it's possible to do the tiled gradient effect I
mention above. I tested WebKit's current gradient implementation, and
that works as expected.
> Which is why you don't need the gradient function itself to have a
> way to repeat the gradient inside itself.
>
> Any UA that supports 'background-repeat', 'background-size', and
> Tab's 'linear-gradient()' should support tiling a properly sized
> gradient with 'background-repeat'. What Gecko does that goes beyond
> this is to adjust the tiling so that the gradients in each tile line
> up with each other. Thus, if you had a 30deg gradient, the tiles of
> 'background-repeat' are not in rows and columns as they normally
> are, but presumably shift each column (or row?) so that the colors
> of the gradient in each tile will line up with its neighbor.
> Although, that doesn't precisely describe how something like 'repeat-
> x' would work with a gradient that includes, say, a 10deg gradient
> or even a top-left to lower-right gradient.
I don't think this can be construed as "adjusting the tiling so that
the gradients line up with eachother", since Gecko also makes radial
gradients repeat, and that can't be described by adjusting the tiles.
What they do is to simply repeat the color stops along the gradient
axis for as long as is necessary to fill the box.
> That is kind of nice behavior, even though it seems like a somewhat
> uncommon need. Perhaps we could eventually add a note to 'background-
> repeat' to explain how to tile generated images like gradients that
> can have a more seamless joining of tiles as with Gecko.
If we want background-repeat to have this magic effect on gradients,
we should just say that it's achieved by repeating the color stops.
However, Tab's approach was to have two more gradient functions
(repeating-linear-gradient, repeating-radial-gradient), which I think
is a bit more honest.
Simon
|
|
Re: [gradients] basics
On Nov 8, 2009, at 1:12 PM, Simon Fraser wrote:
>> Any UA that supports 'background-repeat', 'background-size', and
>> Tab's 'linear-gradient()' should support tiling a properly sized
>> gradient with 'background-repeat'. What Gecko does that goes beyond
>> this is to adjust the tiling so that the gradients in each tile
>> line up with each other. Thus, if you had a 30deg gradient, the
>> tiles of 'background-repeat' are not in rows and columns as they
>> normally are, but presumably shift each column (or row?) so that
>> the colors of the gradient in each tile will line up with its
>> neighbor. Although, that doesn't precisely describe how something
>> like 'repeat-x' would work with a gradient that includes, say, a
>> 10deg gradient or even a top-left to lower-right gradient.
>
> I don't think this can be construed as "adjusting the tiling so that
> the gradients line up with eachother", since Gecko also makes radial
> gradients repeat, and that can't be described by adjusting the tiles.
Agreed. I was limiting myself to talking about linear gradients, and I
admitted that my explanation didn't exactly cover what was happening.
> What they do is to simply repeat the color stops along the gradient
> axis for as long as is necessary to fill the box.
Ah, yes. That is a much better way to describe what is happening there.
>> That is kind of nice behavior, even though it seems like a somewhat
>> uncommon need. Perhaps we could eventually add a note to
>> 'background-repeat' to explain how to tile generated images like
>> gradients that can have a more seamless joining of tiles as with
>> Gecko.
>
> If we want background-repeat to have this magic effect on gradients,
> we should just say that it's achieved by repeating the color stops.
> However, Tab's approach was to have two more gradient functions
> (repeating-linear-gradient, repeating-radial-gradient), which I
> think is a bit more honest.
That really seems unnecessary. I don't see a strong use case for
repeating gradients at all, and much less so for 'list-image', 'border-
image', etc. And for those few times that you do want to have a
gradient repeat as a background, you would pretty much always want it
to repeat in the most intelligent way possible, and it is pretty clear
what that would be: magic. I can't see ANY reason why someone would
want a repeating background gradient in which there were sharp
divisions between the tiles because the colors didn't line up, so that
is where it makes sense for the magic to happen.
|
|
Re: [gradients] basics
On Mon, Nov 9, 2009 at 10:12 AM, Simon Fraser <smfr@...> wrote:
You're right, so it's possible to do the tiled gradient effect I mention above. I tested WebKit's current gradient implementation, and that works as expected.
It works in Gecko too, in the updated gradient implementation. We've stopped treating background-repeat specially for gradients, now it repeats just like any other image. But we did add -moz-repeating-linear-gradient and -moz-repeating-radial-gradient so you can still repeat gradients "properly".
Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
|
|
Re: [gradients] basics
2009/11/8 Brad Kemper < brad.kemper@...>:
> That really seems unnecessary. I don't see a strong use case for repeating
> gradients at all, and much less so for 'list-image', 'border-image', etc.
> And for those few times that you do want to have a gradient repeat as a
> background, you would pretty much always want it to repeat in the most
> intelligent way possible, and it is pretty clear what that would be: magic.
> I can't see ANY reason why someone would want a repeating background
> gradient in which there were sharp divisions between the tiles because the
> colors didn't line up, so that is where it makes sense for the magic to
> happen.
Sorry if I have not been following the gradient discussion, but I fail
to understand why repeating gradients does not have "a strong use
case". The designer is responsible for any background image to line up
(or not line up, if that's the deliberate decision), but repeating
gradients feel quite intuitive to me.
--
cheers,
-ambrose
|
|
Re: [gradients] basics
On Nov 8, 2009, at 2:23 PM, Ambrose LI wrote:
> 2009/11/8 Brad Kemper < brad.kemper@...>:
>> That really seems unnecessary. I don't see a strong use case for
>> repeating
>> gradients at all, and much less so for 'list-image', 'border-
>> image', etc.
>> And for those few times that you do want to have a gradient repeat
>> as a
>> background, you would pretty much always want it to repeat in the
>> most
>> intelligent way possible, and it is pretty clear what that would
>> be: magic.
>> I can't see ANY reason why someone would want a repeating background
>> gradient in which there were sharp divisions between the tiles
>> because the
>> colors didn't line up, so that is where it makes sense for the
>> magic to
>> happen.
>
> Sorry if I have not been following the gradient discussion, but I fail
> to understand why repeating gradients does not have "a strong use
> case". The designer is responsible for any background image to line up
> (or not line up, if that's the deliberate decision), but repeating
> gradients feel quite intuitive to me.
I mean that I rarely see them practice, compared to how ofter I see
non-repeating gradients. And when I do see a repeating gradient (using
a raster image), it is never at an angle that would make it look like
it was obviously tiled. Even with diagonal lines as backgrounds, the
artist ALWAYS carefully constructs the image to avoid obvious
divisions between tiles.
|
|
Re: [gradients] basics
2009/11/8 Brad Kemper < brad.kemper@...>:
>
> I mean that I rarely see them practice, compared to how ofter I see
> non-repeating gradients. And when I do see a repeating gradient (using a
> raster image), it is never at an angle that would make it look like it was
> obviously tiled. Even with diagonal lines as backgrounds, the artist ALWAYS
> carefully constructs the image to avoid obvious divisions between tiles.
I don't know how valid my feeling is, but "not seen in practice" can
mean either of two things: that it is an unnatural use case, or people
are not doing it because it is currently too hard to do it right. If
it is the first, it'd be right for us to reject it as a weak use case;
if it is the second case, we'd be unnecessarily discouraging an
otherwise natural use.
--
cheers,
-ambrose
|
|
Re: [gradients] basics
Brad Kemper wrote:
>
> On Nov 8, 2009, at 10:43 AM, Andrew Fedoniouk wrote:
>
>> background: linear-gradient(magenta yellow) url(...)
>> background: url(...) linear-gradient(magenta yellow)
>
> With the current draft, these would be treated as multiple background
> images, with the last one in the list on the bottom.
See, you have made the same mistake here.
According to current draft these two values of the background will do
nothing as they are simply not valid.
These are valid statements (note use of comma):
background: linear-gradient(magenta yellow), url(...)
background: url(...), linear-gradient(magenta yellow)
> So, no, they are
> not the same thing. But there are certainly reasons to be able to layer
> 2 gradients, or a gradient on top of another image:
>
> * When layering 2 gradients with transparency on the top one (at
> least), you can get more complex gradients that blend colors in
> two or more directions at once.
> * When layering a gradient over some other non-repeating
> background-image (a large logo, for instance), you can create a
> fade-out effect for that image, by blending from a color (matching
> the background-color) to transparent.
> * Similarly, you can create the effect that a normal patterned
> background is fading out as it gets closer to one edge, by putting
> a full-width/height linear-gradient over it that fades from a
> color to transparent.
As a web designer I can imagine use of two gradients (or images) on the
same element. But as an implementor I will not even try to create
possibility to have two or more gradients (images here too) on
background of single element.
To make any sense multilayer gradients should have transparency. In
design tools like image editors you have a luxury to use multiple layers
with alpha-blending but on live, dynamic pages this has to be avoided as
much as possible.
In any case I see value of say these:
foreground-image:url(clock-cover-glass.png)
background-image:url(clock-face.png)
where foreground-image is drawn on top of content layer.
But I see almost no value for, say, this:
background-image:url(clock-face.png),url(clock-cover-glass.png);
It is better to ask designer to combine these images upfront -
visitors will benefit from that.
The same apply to gradients.
>
>
> It seems to me that we've already discussed these arguments at length in
> previous threads, and the working group resolved to continue with the
> concept of gradient-as-image. Let's work on that first, and resolve any
> issues with it before tackling a wider application of the concept to
> anything-with-a-color-can-have-a-gradient-instead.
It is still a proposal, isn't it? If yes so is the discussion.
Just for the note: I have in years support of gradients in CSS in
the form:
background-color: color | color-tl color-tr color-br color-bl;
where four colors define colors in corners of background box.
This simple construction covers most of linear/radial/diamond-gradient
cases and was proven to be very intuitive (for web designers) and simple.
--
Andrew Fedoniouk.
http://terrainformatica.com
|
|
Re: [gradients] basics
On Nov 8, 2009, at 2:44 pm, Andrew Fedoniouk wrote:
>>
> As a web designer I can imagine use of two gradients (or images) on
> the same element. But as an implementor I will not even try to
> create possibility to have two or more gradients (images here too) on
> background of single element.
background-image can already take multiple images:
< http://www.w3.org/TR/css3-background/#the-background-image>
If you implementation has the notion of "generated images", then
supporting multiple background gradients on an element should be
trivial.
> To make any sense multilayer gradients should have transparency. In
> design tools like image editors you have a luxury to use multiple
> layers
> with alpha-blending but on live, dynamic pages this has to be
> avoided as
> much as possible.
>
> In any case I see value of say these:
>
> foreground-image:url(clock-cover-glass.png)
> background-image:url(clock-face.png)
>
> where foreground-image is drawn on top of content layer.
>
> But I see almost no value for, say, this:
> background-image:url(clock-face.png),url(clock-cover-glass.png);
> It is better to ask designer to combine these images upfront -
> visitors will benefit from that.
There are very good arguments for supporting multiple background
images, but let's keep to the gradient discussion here.
> Just for the note: I have in years support of gradients in CSS in
> the form:
> background-color: color | color-tl color-tr color-br color-bl;
>
> where four colors define colors in corners of background box.
> This simple construction covers most of linear/radial/diamond-gradient
> cases and was proven to be very intuitive (for web designers) and
> simple.
The current proposal does not, indeed, have anything that would allow
you to do these types of color blends between corners, or diamond-
shaped gradients.
Simon
|
|
Re: [gradients] basics
On Nov 8, 2009, at 2:44 PM, Andrew Fedoniouk wrote:
> Brad Kemper wrote:
>> On Nov 8, 2009, at 10:43 AM, Andrew Fedoniouk wrote:
>>> background: linear-gradient(magenta yellow) url(...)
>>> background: url(...) linear-gradient(magenta yellow)
>> With the current draft, these would be treated as multiple
>> background images, with the last one in the list on the bottom.
>
> See, you have made the same mistake here.
>
> According to current draft these two values of the background will do
> nothing as they are simply not valid.
>
> These are valid statements (note use of comma):
>
> background: linear-gradient(magenta yellow), url(...)
> background: url(...), linear-gradient(magenta yellow)
You're right; I imagined a comma where there was none.
|
|
Re: [gradients] basics
Brad Kemper wrote:
>
> On Nov 8, 2009, at 2:44 PM, Andrew Fedoniouk wrote:
>
>> Brad Kemper wrote:
>>> On Nov 8, 2009, at 10:43 AM, Andrew Fedoniouk wrote:
>>>> background: linear-gradient(magenta yellow) url(...)
>>>> background: url(...) linear-gradient(magenta yellow)
>>> With the current draft, these would be treated as multiple background
>>> images, with the last one in the list on the bottom.
>>
>> See, you have made the same mistake here.
>>
>> According to current draft these two values of the background will do
>> nothing as they are simply not valid.
>>
>> These are valid statements (note use of comma):
>>
>> background: linear-gradient(magenta yellow), url(...)
>> background: url(...), linear-gradient(magenta yellow)
>
> You're right; I imagined a comma where there was none.
You have missed this case too:
background: url(...), linear-gradient(magenta yellow)
It makes no sense - just waste of resources.
--
Andrew Fedoniouk.
http://terrainformatica.com
|
|
Re: [gradients] basics
On Sun, Nov 8, 2009 at 10:50 AM, Simon Fraser < smfr@...> wrote:
> I think the points made need to be:
> * gradient images have no intrinsic size,
> * therefore they fill the box they are being rendered into (like SVG images
> with no intrinsic size)
> * and therefore, when applied to backrounds, background-size etc have no
> effect.
We can actually be stronger about this - gradient images are infinite
in size (the abstract concept of 'box' used when describing their
rendering has no intrinsic size), and so background-size and
background-repeat have no effect.
I will make this a bit clearer in the introduction to the section.
> If you refer to the CSS 2.1 spec I think you should be more specific about
> which section you are referencing.
Will do.
~TJ
|
|
Re: [gradients] basics
On Sun, Nov 8, 2009 at 9:06 PM, Andrew Fedoniouk
< news@...> wrote:
> background: url(...), linear-gradient(magenta yellow)
>
> It makes no sense - just waste of resources.
Huh? That makes perfect sense - it's an element with two background
layers. The url() references an image on the uppermost layer, and the
gradient is on the lower level. If the first layer has any
transparency, it will show the gradient behind it, exactly as
expected.
~TJ
|
smime.p7s (3K) 