Re: [CSS3] linear-gradient() proposal

As of “it is designed to be simple”...

Problem is that you use “closed” syntax that cannot be extended if we will discover that it is not enough.
If gradients would use extendable syntax like: 

  linear-gradient( angle : 45deg, color-stops: red/0% blue/100%  );

then we can add in future for example this:

  linear-gradient( angle : 45deg, start: 10px 20px, length : 40px, color-stops: red/0% blue/100% );

otherwise (with current proposed syntax) we easily can get into “640k of RAM will satisfy everyone” situation.
AFAIR results of that decision were quite painful couple years after it.

To be short, there are no options other than:
1) to use extendable syntax and define minimalistic case now –or-
2) to define as full as possible feature set upfront. 

I believe that current function notation is not a right tool for the task.
At least functions should allow named arguments.

-- 
Andrew Fedoniouk

http://terrainformatica.com






From: Brad Kemper 
Sent: Tuesday, March 29, 2011 7:47 AM
To: Andrew Fedoniouk 
Cc: Tab Atkins Jr. ; www-style@w3.org 
Subject: Re: [CSS3] linear-gradient() proposal


On Mar 28, 2011, at 8:52 PM, Andrew Fedoniouk wrote:


  Brad, start and end points of linear gradient in your version are non-deterministic in the sense that it is not possible
  to define where gradient starts and where it ends precisely.  So these cases:
  http://terrainformatica.com/w3/linear-align-2.png are simply impossible to define with your schema (sorry for “cauchemar” colors there).

Right. As I said before, it is designed to be simple. That is more important than being able to create any possible gradient that can be created by SVG. There is nowhere near as common a need for the more complex gradients that a more complex syntax allows.


  Radial gradient allows to define precisely where the gradient starts and where it ends with various handy presets:
  http://terrainformatica.com/w3/radial-align-positioning.png

In my opinion, radial gradients are a bit over powered currently, and could be simpler. I expect radial gradients to be much less common than linear gradients, and thus could get by without serving even edgier edge cases. But in any case, Tab designed it in the way that he thought was the right mixture of simplicity and power for the most needed radial gradients.


  I’ve implemented your schema already and discovered that it is quite limiting.
  It is useful in quite narrow range of angles. 
  E.g. this linear-gradient(top left, yellow, blue);
  looks almost the same in your case for angles 30..60. So it is not clear why do you 
  need angles there at all.


Keyword gradients such as "top left" go from corner to corner. Angle gradients stay at a consistent angle no matter what the box size. Specifying the direction via angle is also the most common and familiar way to specify an angle textually in existing software (as I said before). And vanishingly few gradients in the wild need to be so precise as to require two length measurements instead of one for the first or last color stops.