Re: [Proposal] CSS gradients

On Dec 13, 2007, at 12:49 PM, Brad Kemper wrote:

> On Dec 12, 2007, at 9:53 AM, Erik Dahlstrom wrote:
>> 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.
>
> That still seems much more complicated for when you want to just add  
> a simple gradient to an element in a style sheet that is used by  
> possibly hundreds of HTML documents (assuming that by "document" you  
> mean HTML document and not CSS file). I really like the idea of a  
> very simple syntax that could be used as a substitute for color.  
> Especially, if it had some default values, so I could right  
> something like this (with 0% and 100% implied by the order, and  
> linear as a default):
>
> background-color:gradient(90deg, rgba(0,0,255,0.5), transparent)
>
> While I can see how using SVG would be useful in some cases to  
> accomplish similar types of things, I would hate to have to  
> reference a separate list of gradients in a separate file every time  
> I wanted to add a single gradient to a rule in my style sheet.
>
>> 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.
>
> To me, using x/y coordinates for the first two stops and then  
> distances for the remaining stops seems cumbersome. I would much  
> rather see angles indicated by degrees, as that is how I tend to  
> think of them (especially with typical 45 or 90 degree increments),  
> and is typically how they are specified in other applications (such  
> as PhotoShop). What if it were more like the following, with the  
> word "linear" optional for linear gradients, and the distance  
> measures only required if there were not just 0% to 100%:
>

Angles are problematic. First, I'm assuming that we may want gradients  
other than linear at some time in the future, and parsing would be  
easier if the first argument is the "type". If it's radial, we need  
x,y for the center anyway. Why not keep it consistent? Besides, if you  
give it only an angle, there's no way to specify at what x,y the thing  
starts... so it must start at the top left corner or something. What  
if you wanted the bright blue to not face immediately, but give you  
half an inch before starting to face to transparent? Also, 90 degrees  
is by far the least interesting (though possibly would be the most  
used) example you could give... small background images can simulate  
this to a degree. It's only when you're wanting something diagonal  
that the images become cumbersome in size.

> gradient(linear, 90deg, #000 20px, #777 10%, #999 50%, #fff 60% ...)
>
> I'm not sure if you'd want to mix pixels with percentages like that,  
> although I could see that doing so might be useful. If you wanted  
> the angle to be dependant on the box size, then maybe you have some  
> optional key words to replace the angle measurement:
>

Certainly percentages are necessary. And there are probably cases  
where you would want to mix percentages and other units. Unless it  
became difficult to compute (and it shouldn't), mixing would be fine  
with me. Really though, look at it... by going with degrees, you're  
only save yourself two units in the whole gradient. Your first two  
stops still need 1 measurement, mine would have it at two. And it  
would leave you with being able to do less complex gradients. As for  
the keywords, I think angles are already a CSS unit that can be  
defined several ways. Degress, radians, and if I'm not mistaken,  
compass directions. So if angles were used, I think you already have  
that.

> gradient(linear, bottom-left to top-right, #000 20px, #777 10%, #999  
> 50%, #fff 60% ...)
>

John Oyler
john@discrevolt.com

Received on Thursday, 13 December 2007 18:33:17 UTC