Re: [css3-images] Repeating oblique gradients

> For raster images the only sensible
>>> options are to do nothing (transparent everywhere outside the view
>>> box) or to tile it in some way (we chose simple tiling in one or both
>>> directions).  Gradients theoretically have infinite paint, so
>>> background-repeat:extend needs to be defined to give the option "just
>>> use the rest of the image outside of the view box".
>> 
>> Yes, and that effect would be fine for 'background-repeat:no-repeat', if we thing we would never need it to not extend, or a new 'background-repeat:extend' if we want to have it optional. But I see no reason why this should exclude the other 'background-repeat' values if the image is sized down to something less than '100% 100%'.
> 
> I don't understand what you're trying to say here, and so expect that
> we're talking past each other.  background-repeat:extend will make the
> gradient fill the entire background layer with its paint.  

You act as though 'background-repeat:extend' has already been agreed to. All I am saying is that having an 'extend' value there is one idea. Another is to simply let it extend automatically when the value is 'no-repeat'. Which idea is best depends on whether or not it is important to allow 'no-repeat' without automatically extending the color into the non-image area of the background. 

> Resizing the image via background-size just changes the default image
> sizing area, and thus the way the gradient draws itself.  It's
> irrelevant when considering how to fill the rest of the background
> layer.

Well, it's relevant to seeing with you eyes if the color extends or not, or to being able to see more than one tile. 

> 
> It's purely a function of the color-stops.
>> 
>> Not purely, since a background image can be repeated. For multiples of 90deg, you don't even need anything special to make it look good.
> 
> Background images can be tiled with background-repeat, yes.  By a
> happy coincidence, you can simulate a repeating linear gradient using
> background-repeat, when the gradient is angled at a multiple of 90deg.
> That has no bearing on the general problem of a repeating gradient.

A gradient, whether in a raster image or generated by a function, can be tiled with background-repeat. It's not a coincidence, It is exactly what background-repeat was designed to do. 

You want to simulate that inside the function and call it a repeating linear gradient. It is not a happy thing to overcomplicate such an otherwise simple thing in order to replicate what is already possible and in wide use. If there is a problem with the way angled gradients are tiled in backgrounds (and there are, regardless of what is inside the gradient tile), then we have a chance to fix that with a very small change to how backgrounds work. We don't need a new syntax to repeat color-stops inside the image. 

The only "general problem of a repeating gradient" is how they repeat in backgrounds, since all existing evidence shows that backgrounds are the only major place they will be used. 


> 
>>> You can similarly have a repeating gradient with any of those.
>> 
>> OK... and it looks good for horizontal and vertical gradients. I don't see how anything you've said refutes the thing you quoted me on, where I argue that some further monkeying with 'background-repeat' could also make tiled diagonal gradient images look good too.
> 
> Same as above.

Which part?

> 
>>> If we decide that using gradients for things like a corduroy texture
>>> are sufficient to introduce repeating gradients, then I suspect we'd
>>> want to allow this for border-image as well as background-image,
>> 
>> The circumstances in which you could satisfactorily use a *-gradient as a background-image are extremely limited. Most of the time it'd be easier to just use two backgrounds, unless you _really_ need a hole cut in the middle instead of just simulating that with another background layer. It's not worth it to complicate the syntax just for that.
> 
> Did you mean border-image here?  

Yes. 

> Even if you did, I don't understand
> what you're trying to say here.  How does using two images solve the
> problem of wanting a corduroy pattern for your border-image?

Well I don't need any special magic if it is a horizontal or vertical gradient, since border-image can tile it's sides too. 

I just mean that border-image is generally not a useful place to have diagonal gradients anyway, even as raster images. You end up having to 'stretch' them on the sides (because tiling look so bad), and because of that distortion of the angle you have to use corners with a zero dimension, which means you end up with only two sides of the element using the image. 

So for most cases, if an author wants to have a gradient border where the gradient is at an angle other than 0, 90, etc., he'll end up using a background instead of a border-image, and use a solid second background to simulate void inside (a solid white padding box fill, for instance, if the page has a white background and the element is supposed to look transparent). So we're still Back to background tiling. 

Even if you end up saying that 'stretch' doesn't mean stretch the gradient (only its boundary), then repeats inside the image can still be handled by the author just adding more stops. Or if you think it is OK to change the meaning of the word 'stretch' for border-images, then you should also not object to changing border-image tiling to create seamless tiles of diagonal gradients. 

> not
>>> to mention filters.
>> 
>> Which we haven't seen yet, and so can't evaluate how much this would be needed there. Again, let's please start with the simplest syntaxes for the images, and only add to them as needed.
> 
> Building gradient-specific behavior into the background-* properties
> isn't compatible with later tinkering directly in the gradient,
> though.  

Why not? In theory you could have an image box with many repeats in it, and it wouldn't prevent you from having seamless background tiling. The repeats inside the image are just equivalent to adding more stops, as you yourself pointed out. 

> We really do need to decide one way or another right now.

Received on Wednesday, 1 December 2010 00:31:06 UTC