- From: Simon Fraser <smfr@me.com>
- Date: Wed, 08 Sep 2010 09:55:21 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, David Singer <singer@apple.com>, www-style list <www-style@w3.org>
On Sep 7, 2010, at 11:15 PM, fantasai wrote: > On 09/07/2010 09:43 PM, Simon Fraser wrote: >> On Sep 7, 2010, at 8:15 PM, Tab Atkins Jr. wrote: >> >>> On Tue, Sep 7, 2010 at 7:59 PM, fantasai<fantasai.lists@inkedblade.net> wrote: >>>> And you'd rather use a comma than "to"? I think it's clearer to use "to" >>>> since we're separating the colors with commas. >>> >>> I prefer commas because it's more consistent, and it's how nearly >>> every programming language does functions, particularly javascript. >>> >>>> While we're at it, the use of a comma to separate the geometry from the >>>> colors also bothers me for the same reason. >>>> >>>> How about >>>> linear-gradient(<position> [to<position>]? as<color>,<color>, ...) >>>> ? >>> >>> That seems even worse to me. ^_^ >>> >>>> If the problem is DOM access, why not define different interfaces for >>>> them (LinearBoxGradient and LinearAngleGradient), but leave the parsed >>>> syntax the same? >>> >>> That's smfr's call. What do you think, Simon? Would that be sufficient? >> >> It doesn't help with interpolation for animation. > > And how would different functional notation improve that? > It's just notation. It's for ease of author understanding. It's easier to say "only functions of the same time can be interpolated" than "a linear-gradient using an angle cannot be interpolated with a linear-gradient that doesn't use one", especially if we fall into the "angle" or "non-angle" variants in non-obvious cases. Simon
Received on Wednesday, 8 September 2010 16:56:12 UTC