Re: [Proposal] CSS gradients

On Dec 9, 2007, at 3:26 AM, John Oyler wrote:

> SVG isn't appropriate in some instances. My understanding is that  
> SVG is for actual images, or at least elements of them (a curve or  
> shape). We're just talking about background colors here, but more  
> than one of them. Even with the data uri, they'd be messy just for a  
> gradient, and with an external uri to an svg file we're talking  
> another http get for something that's purely style. A single  
> gradient() is no big deal, and uses less bandwidth to get the same  
> information into the renderer, information that is style.
>
> Unlike this proposal, I'd roll all the various parameters into the  
> gradient() function though. Something like:
>
> gradient(linear, #000, x1, y1, #777, x2, y2, #999, d1, #fff, d2 ...)
>
> Where the first color is for the first XY pair, the second color is  
> for the second XY pair (this gives direction), and every subsequent  
> color/d# is a distance and color combo. Variations could be worked  
> up for radial and other types of gradients. Maybe a limit on the  
> colorstops would be needed, but I'd like to see at least 4 or 5 to  
> be possible. I have no idea how difficult it would be to write a  
> parser that puts no practical limit on the number colorstops, though.
>
> Such gradients should be usable anywhere a color is usable,  
> certainly for the color (foreground) and background-color  
> properties, but also for borders and shadows. Of course, only non- 
> gradient() colors should be usable within a gradient().


Yeah, we've been toying with the idea of adding gradients to WebKit  
and had settled on pretty much exactly this syntax.  I think gradients  
should be part of CSS, and that requiring SVG is overkill.

dave
(hyatt@apple.com)

Received on Monday, 10 December 2007 07:58:26 UTC