W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: [css3-images] Proposed Gradients changes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 29 Nov 2010 09:45:20 -0800
Message-ID: <AANLkTinNSmE+DUPjvD2dt_vM7nYBoJRSDwMVvgdyxwan@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Rik Cabanier <cabanier@adobe.com>, www-style list <www-style@w3.org>
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.  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.)

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

(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".)

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

~TJ
Received on Monday, 29 November 2010 17:46:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT