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

Re: radial-gradient() proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 5 Nov 2009 12:46:30 -0800
Message-Id: <19F7ADE2-35B6-4B31-8553-EC39E93BA82F@gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: Brendan Kenny <bckenny@gmail.com>, www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>

On Nov 5, 2009, at 11:32 AM, Simon Fraser <smfr@me.com> wrote:

> Right, but that's the longhand form, and it's OK if it's verbose.  
> Your first example works just as well.

I just don't consider having 10 different ways to specify an angle to  
be an advantage. I feel it is a distinct disadvantage, because it  
makes it harder to learn and harder to quickly grasp what the effect  
will be. We already have the multiple ways to indicate angle (degrees,  
turns, radians, negative numbers, etc.). That's fine. And percentages  
being optional for evenly spaced stops and beginning and ending stops.  
That's good too. I don't want any longer forms forms though, or even  
more ways to create the same gradient.

>
>> Here is how that would look on a square (I've marked the end-points  
>> with red dots):
>>
>> http://www.bradclicks.com/cssplay/XY_gradient.png
>>
>>
>> Now imagine I specified the exact same color blend like this:
>>
>>    linear-gradient(-34deg, yellow 33px, blue calc(100% - 33px));
>> or
>>
>>    linear-gradient(-34deg, yellow 24%, blue 76%);
>>
>> That seems much more clear to me. Now the gradient still fills the  
>> square box, but the yellow and blue are 33px (or 24%) from the  
>> corners at the specified angle and it is still the same gradient  
>> (I've marked those stops with red lines):
>
> This means something different. Here, the author is explicitly  
> stating that they want a gradient at an angle that doesn't change as  
> the box size changes.

Which is something I am suggesting can be handled with a single  
keyword, instead of multiple extra numbers or extra places for numbers.

> My argument is that this is the less common case, so it's OK for the  
> syntax to be more verbose.

My point is that it is such an extreme edge case, that the benefit of  
having it in the syntax does not justify the degredation of syntax  
simplicity.

>
>> http://www.bradclicks.com/cssplay/simpler_gradient.png
>>
>> And then, since this "image" is really dimensionless (not  
>> necessarily square in usage), the angle and fixed distances would  
>> be free to resize and and become different angles, just as they  
>> would if this was an EPS file (if the UA supported EPS).
>
> Wait, you're suggesting that if the author specifies an angle, it  
> might not use that angle if the gradient is drawn into a box with a  
> different aspect ratio? That seems counter-intuitive.

If I resize any other image in a browse or any other software, the  
contents also resize to the new dimensions, no matter how distorted  
(assuming the software allows me to change the aspect ratio of the  
image). As the aspect ratio changes, so does the angle of any lines in  
the image (except for multiples of 90deg). That is totally intuitive.

So, if you just assume a square when specifying the angle, the results  
of fitting the square to other aspect ratios is completely  
predictable. It bcemes exactly like an eps file in a page layout program

In the cases where you want something else, then you are asking for  
magic, something that makes this different from most other images. I  
say do ghat with a keyword.

>
>> If you actually wanted the magic implicit in the current draft  
>> (that is, the dimensions and angles stayed the same, regardless of  
>> the final used dimensions of the image), then you could introduce a  
>> keyword to make that explicit. So, thus, the following would keep  
>> the angle the same regardless of the image being stretched wide or  
>> tall:
>>
>>    linear-gradient(-34deg fixed, yellow 24%, blue 76%);
>>
>> and if you wanted to keep the distances fixed too, then you would  
>> use length measures with the keyword:
>>
>>    linear-gradient(-34deg fixed, yellow 33px, blue calc(100% -  
>> 33px));
>
> I don't seen the need for 'fixed'. If the author specifies an angle,  
> it's an indication that they want the angle to take precedence; the  
> gradient should always use that angle.

It greatly simplifies the syntax to have it act like an angle as it  
would in other image formats as a default, and to use the keyword to  
mean that something else should happen. It allows you to have your  
cake and eat it too, without adding so many more numbers in different  
places. There is thus exactly one simple mechanism to specify the  
direction (angle), and exactly one simple way to indicate where colors  
should start and stop (color stops).

> I just talked to our local designer, and asked him how he thought  
> about gradients in his head. He immediately talked about two  
> endpoints, rather than thinking of angles. In other words, he  
> thinking of the gradient tool in Photoshop, not the Gradient Overlay  
> layer effect.

I am also a designer who uses the gradient tool in Photoshop. When I  
pick the beginning point, I do not measure from top and left  
separately. Same for ending point.  I think about the direction first,  
then click once for where to start the color on that path, and once  
more for for the end of that path. 
Received on Thursday, 5 November 2009 20:47:25 GMT

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