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

Re: [gradients] basics

From: Brad Kemper <brad.kemper@gmail.com>
Date: Tue, 8 Dec 2009 09:50:12 -0800
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style <www-style@w3.org>
Message-Id: <B05F826F-F039-43F3-AB4D-44F33D8B5964@gmail.com>
To: Tab Atkins Jr. <jackalmage@gmail.com>

On Dec 7, 2009, at 4:25 PM, Tab Atkins Jr. wrote:

> On Mon, Dec 7, 2009 at 12:25 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> Just to revive this topic a little. I kind of like the idea, actually, but not all the time. For instance, take a look at the following, which used PNGs to simulate what a linear-gradient could do:
>> http://www.bradclicks.com/cssplay/linear-gradient/chrome.html
>> The idea is that the top layer of the background is only covering the bottom half of the gradient below it. You can see this in a recent Webkit download, and it works, and I like it. The code is this:
> Ah, cool.  The effect was subtle enough that I had to play with the
> page before I realized what you were doing, and why it wasn't doable
> with the infinite-extend gradient.
> All right then, makes sense.
>> I was thinking that perhaps to get the "infinite outside" effect you bring up, then maybe there could be a new value, such as 'background-repeat: extend' that would not repeat the image, but would should its outside, clipped only by the background painting area.
> So under a standard no-repeat value, the gradient itself would
> actually be the size of the background painting area, but with
> 'extend' it would be infinite in extent and merely clipped to the
> background painting area when painting occurs?

Yeah, something like that.

> This still doesn't seem consistent with how no-repeat works for other
> images, though.  

With other images, the entire image fits within the 'background-size' dimensions. I am saying gradients should also, except when there is some value to say otherwise.

> A too-large image isn't chopped to fit in the
> background area;
> if you move it around with background-position or
> resize it with background-size, you still get the whole thing.

Perhaps I am misunderstanding what you mean, but: How is 'background-position' is relevant, except to refer to how those offsets (or a 'background-size' greater than 100% in either dimension) can cause the image to be clipped by the background painting area? And it absolutely does get clipped by the background painting area, except in the case of the root element that uses an infinite canvas to paint the background on.

But again, that really has little to do with clipping to the bounds of the size of the image itself (a size determined by 'background-size') or not. Clipping to the background painting area clips all background, regardless of any clipping that happens within it first.

> I don't think that adding some special value in background-repeat is
> the correct way to address infinite images, for the same reason I
> didn't think it was appropriate to have background-repeat affect
> whether or not a gradient repeated.  These are things that happen
> *after* the image is created, not before/during.

I think we are probably fundamentally apposed then. I really hate to see background-like properties duplicated (or nearly so) within the image itself, especially in order to create effects that are primarily useful for backgrounds. You end up with ways to do the same thing outside the image as inside, and that just muddies the waters.

With the repeat effect, you are talking about something that few authors need to begin with. For those that do want an infinitely repeating linear gradient, its not going to be in a list-item-image, its going to almost always be in a background (you could put it into a border-image with 1px or 0px slices, I suppose, but its not terribly useful that way, and you are mostly just simulating a background layer anyway at that point). 

With a gradient with an angle in multiples of 90deg you wouldn't even be able to tell the difference between a gradient repeated within the image or one created with the normal background-repeat. And using background-repeat on a sized-down image of, say, an 30deg gradient is just going to look ugly, period. I would much, much rather have a little magic to make the "tiling" of the gradient seamless and expected, than to try to shove more and more background features into an image generating function.

As for extending the gradient background to the edge of the background painting area when 'background-size' makes it smaller or 'background-position' pushes would otherwise reveal background-color, this seems like something you would only want when the tiles are not repeating, so setting it as a value of 'background-repeat' makes the most sense to me for that.

> So, essentially, if the background-repeat value affects image
> generation, it's sort of nasty imo (leaking of levels, and certain
> effects becoming bound to background-* properties that would be useful
> in the other places where gradients can be used).  If it affects
> things after image generation, then we're bound by legacy constraints
> that we should be consistent with, in that no-repeat doesn't clip
> anything.

I see a nastier leak of background properties into your image generating function. I don't want an image generator that creates a complete background within a function, just for the sake of purity over when something is normally created, and I don't even want to start down that road. If you really need anything that complex, you can create it with SVG.

The "extend the background until it gets clipped by something else" effect is not something that would be useful for list markers or border-images. You would end up with gradients covering the whole viewport. It is only useful as a background effect, and only when the gradient is not repeating. It is most useful when using 'background-size' to tweak the size of the entire gradient.

If you want something within the linear-gradient function itself to adjust the beginning and ending color stops, you already have that, and can then let the image fill the background painting area (or list marker or border image).

> If you want a finite gradient, the best thing to do is to find a way
> to chop the image to the size you want.  

Or I can use 'background-size' like every other image, and not repeat it. If you want an infinite gradient, the best thing to do is to find a way to trigger that for your background (the only place it is useful).

> -moz-image-rect() partially
> does this, producing a new image at the dimensions you specify.  If we
> pull that into Images and make it a touch more powerful (frex, give it
> the ability to use % to refer to the box dimensions?) or produce
> something similar that does what we want, it would work better.

I disagree. We already have everything we need to size and position an image in a background. The example I gave is just one case where I wouldn't want the image to repeat. Here is another:


Received on Tuesday, 8 December 2009 17:50:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:41 UTC