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

Re: [css3-images] my take on linear gradients

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 22 Oct 2010 10:02:30 -0700
Cc: "www-style list" <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
Message-Id: <B4700835-370F-40C0-BD33-530F72275A68@gmail.com>
To: "Andrew Fedoniouk" <news@terrainformatica.com>

On Oct 20, 2010, at 10:47 PM, Andrew Fedoniouk wrote:

> ?--------------------------------------------------
> From: "Brad Kemper" <brad.kemper@gmail.com>
> Sent: Wednesday, October 20, 2010 9:47 PM
> To: "www-style list" <www-style@w3.org>
> Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
> Subject: [css3-images] my take on linear gradients
> 
>> I have written and uploaded my thoughts on the linear-gradient draft. I start out with assumptions about what I think is important for any linear gradient syntax, then I examine how well these goals are met by the current syntax, and finally I say what I would change and how that would make it better. You can read it all here:
>> 
>> http://www.bradclicks.com/cssplay/linear-gradient/index.html
>> 
>> I started this last year, then put it aside for almost a year, and just recently finished it. Since the draft changed during that time, I have added some notes about the relevancy of some of the things I had written already, and also updated some other text to match the newer syntax. But note that one or two of the illustrations might use the older syntax (even though the general points they make are still pretty valid).
>> 
>> Part of the early part of the document shows why I think degree-based directions should be counter-clockwise from a rightward-pointing zero, but that is not all that this is about. And I hope that my tone in the document does not come off as being disrespectful of the work that Tab did on the spec so far.
>> 
> 
> Well put, Brad!

Thank you.


> 
> Here is my note.
> 
> All gradient samples you use in your document can be presented by using
> colors-in-corners schema. Imagine that we have background-color property
> that allows to define colors in corners of rectangle:
> background-color: color | < top-left-color top-right-color bottom-right-color bottom-left-color>
> 
> So this:
> http://www.bradclicks.com/cssplay/linear-gradient/example-1.png
> 
> can be defined as:
> 
> background-color: yellow yellow red red;
> 
> And this (square):
> http://www.bradclicks.com/cssplay/linear-gradient/corner-to-corner-as-square.png
> as
> background-color: red black red red;
> 
> Even this
> 
> http://www.bradclicks.com/cssplay/linear-gradient/example-2.1.png
> 
> or this
> 
> http://www.bradclicks.com/cssplay/linear-gradient/rotation_diagram_complex.png
> 
> can be defined by four colors + use of background-size/position.
> 
> I mean that definitions like:
> 
> background-color: yellow red green blue;
> 
> are very simple and cover most of use cases indeed.
> 
> The only thing that it does not cover is gradient that use more than two
> color stops. But it allows to define diamond gradients instead.
> 
> I am not saying that it is a perfect solution. But it is very simple.

Yes, it is pretty simple and uses a familiar syntax. But I think it is not quite powerful enough. While I do expect two-color gradients to be the most common, I think 3-color gradients will also be a pretty common need. Also, I would want to be able to handle gradients with a set length in them, as this is what has been available for many years via raster background images. So, for instance:

linear-gradient(90deg, orange, white 200px)
linear-gradient(90deg, orange, orange 200px, white)

I feel strongly that the degree notation is the simplest and most familiar way to specify a gradient via text entry, and that is why degrees are used almost universally for text entry of gradients in graphics programs that offer that. With the addition of my proposed keyword, it offers all the power needed for at least 99% of the cases IMO, with no need for a separate <bg-position> version, and with SVG filling in for the more extreme edge cases.
Received on Friday, 22 October 2010 17:03:09 GMT

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