- From: Brian Manthos <brianman@microsoft.com>
- Date: Mon, 31 Oct 2011 06:19:32 +0000
- To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
> linear-gradient( [ <angle> | from <side-or-corner> ] > as <color-stop> [, <color-stop>]+ ) IMO, that's an arbitrary change that has negative value. The existing syntax for linear-gradient is of the form... linear-gradient( <direction>, <color-stop>[, <color-stop>]+ ) The existing syntax for radial-gradient is of the form... radial-gradient( <position>, <sizeOrShape>, <color-stop>[, <color-stop>]+ ) There were two concerns I saw supported in the IRC log: 1. position is required for explicit sizing; that priority is backwards 2. with either ordereing of position and sizeOrShape, some syntactic sugar in the form of a keyword would help readability As such, that pushes us toward... radial-gradient(<sizeOrShape> [with <position>]?, <color-stop>[, <color-stop>]+ ) Note that you can then rewrite them as... <linear-gradient> = linear-gradient(<linear-params>, <color-stop>[, <color-stop>]+) <radial-gradient> = radial-gradient(<radial-params>, <color-stop>[, <color-stop>]+) <linear-params> = [ <angle> | from <side-or-corner> ] <radial-params> = (<sizeOrShape> [with <position>]? Notice the consistency between the two. Replacing the comma before the first <color-stop> is graituitous, doesn't advance the cause of readability, and makes the syntax longer and parser (slightly) more complicated. I don't see the win, but I see a negative in reopening the <linear-gradient> grammar without having a REALLY good reason. Reopening that debate is a waste of everyone's time, and moves the timeline for the spec and implementations later into the future.
Received on Monday, 31 October 2011 06:20:32 UTC