Re: [css3-images] Repeating oblique gradients

On Dec 1, 2010, at 5:42 PM, Tab Atkins Jr. wrote:

> On Wed, Dec 1, 2010 at 5:33 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Dec 1, 2010, at 5:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>> I was talking about the repeating-*-gradient() functions, which Moz
>>> has implemented behind a prefix right now.
>> 
>> Ah, I stand corrected.
>> 
>> So, having twice as many gradient functions is preferable to just making background-repeat work better then?
> 
> Yes.
> 
> Having separate functions makes it easier to intuit the differences in
> transition-ability (the number of color-stops doesn't matter for
> repeating gradients, as they effectively have infinite of them, and
> thus you can always match up color-stops between any two repeating
> gradients).

I guess that is something to consider. I'm not sure the results would be all that pretty, or if there might be a way to unlike-number transitions that look just as good or better without repeating, but whatever. It isn't either-or. It doesn't prevent us from adapting background-repeat to work better with linear gradients. Please read on before arguing that point.

> It also avoids having magic behavior tied to background-repeat, where
> setting 'repeat' on a linear gradient tiles and then rotates the whole
> layer, while setting it on radial gradients just tiles.
> background-repeat stays consistent and orthogonal in its behavior.

It's no more magic than anything else, other than that it adjusts its behavior based on information the image provides. Similarly, 'background-size:auto' dimensions an image tile based on information that raster images provide; is that horrible "magic"? Is it non-consistent that raster images that don't contain the same sort of information that would be relevant to 'background-size' don't somehow apply it anyway?

Radial gradients don't present the same problems when background-tiling that linear gradients do.

> Finally, it ensures feature parity between the two types of gradients
> - you can tile *or* repeat both gradients.

Not as nicely.

> (And, of course, this is all dependent on me actually uncommenting the
> section on repeating gradients.)

Even if you do add repeating gradients, that is still repeating within each image tile. How on earth does this prevent you from tweaking how 'background-repeat' tiles each linear-gradient tile? If 'background-repeat' was adjusted to deal better with tiles having an angled linear gradient, you would *still* be able to tile *or* repeat both gradients. 

Your argument is circular: you say that we can't fix the way linear-gradient images are tiled because then you would have to change radial gradients too for consistency, but we can't change radial gradients too because it would be nonsensical and unneeded and wouldn't even make them multiple tiles any more, and therefore is inconsistent. 

In other words, we can't do it because then we'd also have to do something else to be consistent, but we can't do that something else because that would make it inconsistent. If you don't to cram the fix for the way diagonal linear-gradient images tile into the way radial-gradient images tile, then you don't have this problem. And you can STILL add in repeating gradient functions later if you want; this doesn't change that.

Using background properties to tile gradients is a powerful feature that should not be dismissed to out-of-hand. Consider the following:

DIV {
	background-image: url(gradient-v.png);
	background-image: linear-gradient(90deg, white 1px, black 1px, black 2px, #444 2px, #bbb );
	background-size: 100% 20px;
}

With this (untested, except in my head), I should get a nice dark, ribbed looking background , with one pixel of black and one pixel of white on either side of the color blend. And I have a raster image as fallback (probably without the 1px edges, to make it more flexible). 

Whatever I do now using background properties will work at least as well for the linear-gradient as it does for the raster image. For instance, I can change the height of the image, easily adjust where the tiling starts vertically, and also animate the background-position or background-size. With my proposed change to the spec, I could also make one change to the direction of the gradient to, say, 75%, as a progressive enhancement, and it would Just Work.

Here's another example:

 DIV {
	background-image: url(h-groove.png);
	background-image: linear-gradient(90deg, #999, #ddd 5px, white );
	background-size: 100% 10%;
}

This should get me 10 horizontal lines as a background, with each 5px-thick line blending vertically from a lightish gray to a lighter gray. And I can change the number of lines that are evenly distributed by simply changing the vertical dimension of background-size. In the fallback, the line width also changes, but still doesn't look too bad if I stick with light colors, high-enough image resolution (not a problem, since the image only needs to be 1px wide), and maybe go for something intentionally a little blurry on the line part.

Or a small variation:

 DIV {
	background-image: url(h-groove.png);
	background-image: linear-gradient(90deg, #999, #ddd 5px, white );
	background-size: 100% 75px;
	background-repeat:space;
}
 
With this version, the background size remains fixed, and the UA doesn't even need to know about 'background-size' if it is using the raster image (progressive enhancement, again). I don't get an exact number of tiles, but with more modern UAs that understand the linear-gradient and 'background-repeat:space' I do get them evenly spaced tiles at an approximate height.

The point is, as an author I can use the same methods and techniques as I do for raster images in backgrounds. It's not a "happy coincidence", it is a standard operating procedure, and tells a good fallback story. With my suggestion to adapt 'background-repeat', we have the opportunity to make these techniques, and all the power and advantages that go with them, work equally well for oblique linear gradients that would otherwise produce ugly results. It makes using angled linear gradients in backgrounds simple, with a minimum of extra fuss over how it works today. A UA could never do that when using only raster images for gradients, but now it should be a relatively simple matter (algorithmically anyway; I can't say anything meaningful about the actual program code).

And if we still think there is a need for repeating-*-gradient(), then you can still add that back in. But I suspect that there no longer would be. Linear repeats in backgrounds would be the highest need, and this would take care of that. Repeating concentric circle gradients are pretty rare, by comparison.

Received on Thursday, 2 December 2010 17:02:49 UTC