- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 19 Apr 2010 14:05:37 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Simon Fraser <smfr@me.com>, public-fx@w3.org
On Mon, Apr 19, 2010 at 11:56 AM, L. David Baron <dbaron@dbaron.org> wrote: > On Monday 2010-04-19 11:30 -0700, Tab Atkins Jr. wrote: >> On Mon, Apr 19, 2010 at 10:56 AM, Simon Fraser <smfr@me.com> wrote: >> > We should be able to interpolate linear-gradient() and radial-gradient() >> > images by interpolating the colors and color-stops, given some rules >> > about when the match closely enough to be interpolatable. >> >> The most basic and simple rule, obviously, is that if the start and >> end gradients have the same number of color-stops, then you simply >> pair the stops up in order and interpolate their positions and colors >> in the established manner. >> >> At the moment I can't think of any more complex rule that would work >> in general. If an author wishes to, say, transition from a 2-stop to >> a 3-stop gradient, they can currently hack it by manually upgrading >> the 2-stop to a 3-stop, by adding an additional stop that matches >> whatever the color would be at the point they want. (That is, if they >> are animating linear-gradient(white,black) to linear-gradient(yellow, >> green, blue), they can just change the first one to instead be >> linear-gradient(white, #808080, black).) > > Let's call your proposal (which is what used to be in the > transitions spec) (1). > > I can think of two ways to animate gradients that would work more > generally: > > (2) Cross-fade the colors along the gradient line (i.e., in %-age > space), and simultaneously animate the position of the gradient > line. (this works between gradients and solid colors, but not > gradients and images) Would the idea be to "fall back" to doing (2) if (1) doesn't apply, or to just do (2) at all times? We'd obviously fall back to (3) for the most general case. > (3) pure cross-fade (which even works between gradients and images) > > It would be interesting to see if there are important use cases that > can be handled by (1) or (2) that don't work with (3). (One that's > been mentioned is widening or narrowing a gradient. Is this > important?) Widening or narrowing a gradient is precisely what we'll be doing if you auto-size a gradient background and then transition the size. It would be weird if you couldn't do that slightly more manually. (As an example of this effect in use, consider a heading for a section of an app that uses a narrow, subtle gradient. When you activate the section, the gradient expands and becomes more prominent. Say, linear-gradient(white 30%, #eee 50%, white 70%) to linear-gradient(white, #ccc 50%, white).) >> > functions (of which we have one already, which is CSS gradients). Some >> > suggested image generation functions are: >> > >> > solid-color(r, g, b, a) > > Why not just allow <color> values where images can go? There is a potential ambiguity problem with the background shorthand, but that should be resolveable without too much difficulty. (On any background layer but the last, a color is taken as an <image>. On the last background layer, we have some vaguely intelligent behavior - if there's a single color, it's taken as a background color/image, if there's two colors we define whether the first is an image and the second a color, or vice versa.) ~TJ
Received on Monday, 19 April 2010 21:06:29 UTC