Re: [css3-images] Proposed Gradients changes

On Nov 29, 2010, at 11:55 AM, Rik Cabanier <cabanier@adobe.com> wrote:

> I agree.
> If we use your logic and add a background-rotate parameter, gradients can be simplified to just their colorstops.

That goes a bit further than I would take it. I still think a direction is a pretty essential part of any linear gradient, not just those used for backgrounds. 

> They would no longer need their positioning or scaling parameters because those would be specified in the background parameters. 
> Axial and radial gradients would have the same syntax in this world (unless you want to have support for focal point).
> 
> There would be a need to 'pad' the edges of a gradient in the case of non-repeating background. In the case of:
>    background-image: linear-gradient(black, white); background-repeat:no-repeat; background-rotate: 45deg;
> the corners of the bounding box would have to be filled with padded colors.

Yeah, we've discussed ways of letting the color bleed out beyond the rectangle of the image. It is not clear to me whether that should be automatic, or handled by some background value. 


> -----Original Message-----
> From: Brad Kemper [mailto:brad.kemper@gmail.com] 
> Sent: Monday, November 29, 2010 10:10 AM
> To: Tab Atkins Jr.
> Cc: Rik Cabanier; www-style list
> Subject: Re: [css3-images] Proposed Gradients changes
> 
> 
> On Nov 29, 2010, at 9:45 AM, Tab Atkins Jr. wrote:
> 
>> On Mon, Nov 29, 2010 at 7:31 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On Nov 28, 2010, at 11:38 PM, Rik Cabanier wrote:
>>>> The radial gradient spec seems more complicated than it needs to be.
>>>> Extending my proposal for axial to radial:
>>>> radial-gradient(startx starty endx endy, radius1 radius2 ratio, 
>>>> endpoint-color,...) with startx, starty = position of the 
>>>> centerpoint of first endpoint (default: center center like 
>>>> background-position) endx, endy = position of the centerpoint of the 
>>>> last endpoint (default: center center)
>>>> radius1 = radius of the inner circle (default: 0% like 
>>>> background-size)
>>>> radius2 = radius of the outer circle (default: 50%) ratio = the 
>>>> ratio of the height/width of the circle. (default: auto = ratio of 
>>>> the bounding box)
>>>> 
>>>> wouldn't this cover most of what you're trying to accomplish? My proposal also includes moving the focal point.
>>> 
>>> Actually, if you suppose that most radial gradients are going to be used in backgrounds, then the current syntax is already over-complex, and should just be reduced down to the following, to be centered in the image box  and filling it to the sides:
>>> 
>>> radial-gradient(<color-stop>[, <color-stop>]+)
>> 
>> Not true.  At the very least, centering a radial gradient on the box 
>> corners semms common/useful enough that I want to address it.
> 
> It's not true "if you suppose that most radial gradients are going to be used in backgrounds", as I stipulated? Why couldn't you do that via 'background-position:-50% -50%; background-size:200% 200%' (or other sizes)? It is true.
> 
>> And you
>> need the ability to express intermediate forms, so that immediately 
>> gets you the fully general centering ability.  (You could restrict it 
>> more, but it would be equal or greater complexity, so there's not much
>> use.)
> 
> And you have that ability with 'background-position'.
> 
>> That said, "radial-gradient(<color-stop>[, <color-stop>]+)" is allowed 
>> and does exactly what you say.  That's intentional.  ^_^
>> 
>>> The rest could be mostly handled by background properties, especially 'background-position' and 'background-size'.* Any other added complexity to the syntax would mainly benefit 'list-style-image'. I can't see that there would be a lot of demand for stretched radial gradients with a lot of controls in border images. So really the question is how much more control do we really need for bullet point radial gradients, which would also give a little more control in border-image radial gradients as a bonus? Or does anyone really think it is important to be able to tile radial gradients that are clipped in unusual ways to rectangular boxes, without using SVG to do it?
>> 
>> Bullet-point gradients don't need as much controls as background 
>> gradients.  Centered 'contain' circles would be sufficient for 
>> basically all cases.  (And since the 'default image sizing area' of 
>> list bullets is a 1em square, you don't even need the extra constraint 
>> of 'circles', because ellipses would do the same job.)
> 
> Yeah, that's my point.
> 
>> (Returning to my earlier point about corner-centered gradients, you
>> *could* do them by setting, say, "background-position:-50% -50%;
>> background-size: 200% 200%;", but that's more complex and less obvious 
>> than just telling the original gradient "top left".)
> 
> How is it more complex? Everyone who works with backgrounds already knows the background syntax or is looking it up anyway. It is perfectly obvious that if you have an image of a centered radial gradient, then you would use background-position to move that center to the corner of the element. You don't need a special syntax to move it to the corner of the image instead.
> 
> You are just unnecessarily adding a bunch of stuff to the inside of the function that replicates what is already easily available. That is not a good thing. Keep background positioning within the background-position property; it isn't needed anywhere else. Then use whatever background-size you want. It seems like you want to discourage people from using the standard background properties to do what they were intended to do.
> 
>>> * I would also propose that 'background-size:cover' would work a little differently for radial-gradient images, so that the gradient goes from center to corners ('background-size:contain' would go from center to edges).
>> 
>> That sort of interaction is why I prefer baking the controls into 
>> gradients themselves, rather than relying on hooks with other 
>> properties.  I think it results in an API that is slightly larger, but 
>> cleaner and simpler.
> 
> Nonsense. If I want to tile a background, I should be able to do it using the standard background image tiling properties.  I don't need another layer of complexity within the image generation, to multiply into where each color starts and stops. I just need a few tweaks to the background properties to handle a few special needs of gradients (specifically, those angles that don't repeat as seamlessly otherwise, and create bad results when used as-is).
> 
>

Received on Monday, 29 November 2010 20:31:37 UTC