- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Wed, 12 Aug 2015 17:23:31 -0600
- To: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org list" <www-style@w3.org>, "www-svg@w3.org list" <www-svg@w3.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Dirk Schulze <dschulze@adobe.com>
- Message-ID: <CAFDDJ7whiLh_UMcGvF=x6P4vphg1Kch=KpOeyDfJJKx-DfYy1g@mail.gmail.com>
I do not know of any user agent that has implemented transitions from one SVG gradient to another (except by animating the SVG gradient <stop> elements themselves), so changing the draft text should not be problematic. (I don't have an Apple device to test with at the moment; if someone wants to give it a go to confirm please let us know.) The SMIL behavior was to animate changes in a url(#paint) reference in discrete switches. Many implementations are currently buggy even doing that, and I'm not sure whether any do it for CSS animations/transitions yet (i.e., whether they animate it in the sense that the change is affected by a transition delay or step function, or applies at all when specified in keyframes). As much as it sounds nice to be able to transition between SVG gradients, I agree with the arguments relating to the lack of specifiable intermediate values. The only way you could define an intermediate value would be if you mapped both initial and final SVG gradients to CSS gradient functions and transitioned the functions. That is currently not practical because there are features of SVG gradients which cannot yet be represented in CSS gradient functions. It also just sounds like an implementation headache: what if the DOM or styles for the SVG gradient elements were also changing? I like the idea of applying cross-fade transitions to SVG paint server content. That should address most use cases with acceptably smooth results. It may be worth discussing how the scaling as well as fading transition would apply to an SVG pattern (i.e., is it treated as a single image or a tiled image? if tiled, how do you incorporate pattern transformations?). Transitioning direct color values in an SVG paint property (fill/stroke) is well supported for SMIL and CSS in every user agent that supports those animation types for SVG. ~ABR On 12 August 2015 at 16:24, L. David Baron <dbaron@dbaron.org> wrote: > On Thursday 2013-04-18 10:37 -0700, Tab Atkins Jr. wrote: > > On Thu, Apr 18, 2013 at 10:32 AM, Dirk Schulze <dschulze@adobe.com> > wrote: > > > Hi, > > > > > > CSS3 Transitions defines animations of paint servers [1]: > > > > > > "" > > > • paint server (SVG): interpolation is only supported between: > gradient to gradient and color to color. They then work as above. > > > "" > > > > > > This seems to be incompatible with the current model of SVG resources > and SVG animation. Currently elements themselves can have triggered > animations. It is not possible in SVG at the moment to make a style change > on one element affect the content (DOM or SVGDOM) of another one. From the > author perspective it might seems quite plausible. However, it needs more > discussion and specification work in the SVG WG and SVG specification. > Since animations are from one url to another url, it is unclear how it > could be specified at all and how the intermediate results affect the two > resources. > > > > > > I would suggest that CSS Transitions treats paint server references > the same as keywords. Note that paint servers are just <linearGradient>, > <radialGradient>, <pattern> and possibly <color> elements. The animation of > CSS colors on 'fill' and 'stroke' won't be affected and still work as > described in the spec. > > > > > > The feature can be added to a future version of the spec when we > outlined this concept. > > > > Given that you can't construct an intermediate value between two > > references, I agree with this. They should fall into the generic > > "image" bucket, which transitions with cross-fade() (this transition > > behavior is defined in Images 4, not Transitions). > > > > When an SVG paint server is literally a color, not a referenced to a > > <solidColor> element, it should transition as a color, though. > > This seems reasonable to me. Is it compatible with implementations? > I believe the old wording dates back to the original Apple > transitions proposal. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) >
Received on Wednesday, 12 August 2015 23:24:01 UTC