Re: [Proposal] CSS gradients

On Sun, 09 Dec 2007 10:26:58 +0100, John Oyler <johnoyler.css@gmail.com>  
wrote:

>
>
> On Dec 8, 2007, at 5:05 PM, fantasai wrote:
>
>>
>> Charles A. Landemaine wrote:
>>> Hello,
>>> Here's my proposal for the next specifications of CSS:
>>> We could style elements using scalable gradients using fixed and
>>> variable units. For instance ...
>>> I have uploaded an example for you to see better:
>>> http://www.imgplace.com/directory/dir3583/1197135240.png
>>> I hope you like the idea.
>>
>> Hiya Charles,
>>
>> I think we'll probably leave the gradient definitions with SVG:
>> you can use an SVG image to define the gradients (which gives you
>> a lot more flexibility than we could ever reasonably define in
>> CSS) and position it using the CSS3 Backgrounds and Borders
>> properties:
>> http://www.w3.org/TR/css3-background/
>>
>
> 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.

Not if you use relative uri:s which point to svg elements that are part of  
the document you're styling.

> A single gradient() is no big deal, and uses less bandwidth to get the  
> same information into the renderer, information that is style.

You can't re-use parts of other gradient specifications in this proposal  
as far as I can tell. Svg does handle that.
And you may actually want to be able to style the colors in the gradient  
with a stylesheet. Svg+css does that for you too.

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

If you want to use many colorstops: svg imposes no limit on the number of  
them you can have.

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

Another way is to support the 'fill' and 'stroke' properties from svg on  
the content that is styled (read: HTML).

> Linear and radial should be required to comply with the spec, but other  
> types would be optional or as part of a later spec, I dunno.
>
> In addition to other parts of CSS2 and 3 (border-radius, opacity, and  
> shadows come to mind), such gradients would make background images  
> unnecessary on a large number of websites. Slashdot comes to mind.
>
>
>> More browsers are supporting SVG, so I expect we'll see SVG as
>> background images become a practical solution for gradient
>> backgrounds on the Web.
>>
>
> Possible, but hardly practical. Another get, to fetch each SVG image, or  
> really really ugly css with the data uri. All for what should probably  
> be properly style.

Depends on how you author the svg, either make it part of the styled  
content (HTML+SVG) or combine it into one svg file.

> And background images aren't the only place you might want to use a  
> gradient, foreground colors are nearly as important. How could you make  
> an h1 a horizontal gradient from left to right, red to blue?

Simple, just support the 'fill' property from svg on the h1. It is the aim  
of the SVG 1.2 Paint Servers spec to allow other languages than svg to use  
the same functionality and definitions that are already working in svg.

> If you use SVG, it loses whatever semantic meaning the html element has,  
> as I understand things.

Well, replacing the h1 with svg elements then yes you have something  
different. However, just having a background that is an svg doesn't mean  
that the h1 loses its semantic meaning as I see it.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
http://my.opera.com/macdev_ed

Received on Wednesday, 12 December 2007 19:52:29 UTC