Re: [css3-images] Repeating oblique gradients

> On Tue, Nov 30, 2010 at 9:42 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> I think that repeating a pattern in one or two directions should stay in the background-repeat property, as it is already and has been for many years. It has to do it anyway; it is just a matter of whether it will do it elegantly or not. So if we look at that property, we see that for any diagonal gradient the results are ugly and unlikely to be what any author would want (generally speaking). So we can either add some magic to it to automatically turn 'background-repeat: repeat-y' into 'background-repeat:repeat-in-the-direction-of-the-gradient-angle' or something (which someone pointed out problems with some time ago, although I don't recall the specific argument), or we can add another value or two to 'background-repeat'. But the point is, once this is solved for backgrounds that use images, then it doesn't need to re-solved for the images themselves. Unless someone can prove that this is really also an important need for images in other places (like filters) that don't have their own flexibility of sizing, repeating, and moving the image around.
> 
> Pushing gradient repetition into background-repeat still isn't a good
> idea, as I argued in the past.  

Unconvincingly. 

> Background-repeat really just
> describes how to transform a finite-size background image into an
> infinite background layer.  

Gradient images can be finite sized, via 'background-size'. 

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

> Whether or not a gradient repeats, though, has nothing to do with the
> above.  

Why not? You're saying the values for 'background-repeat' and/or 'background-size' should be ignored when you don't have 'background-repeat:extend'??

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

> You can have a
> normal gradient with background-repeat of none, repeat, or extend.

That contradicts your previous two statements about repeats of gradients only being in the color stops, and having nothing to do with tiling via background-repeat. And what happened to repeat-x, repeat-y, round, and space? These should all continue to work if background-size is small enough. 

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

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

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

Received on Tuesday, 30 November 2010 21:23:14 UTC