Re: CSS Animations and Transitions on SVG Attributes

wow! That's great!
Now all we need is a good synchronisation model and CSS animations can
become very useful [?]

Rik

On Thu, Dec 1, 2011 at 4:21 PM, Dean Jackson <dino@apple.com> wrote:

> FYI - top of tree WebKit supports CSS Animations and Transitions of SVG
> style properties.
>
> Also, a patch just landed that allows CSS Transforms to be applied to SVG
> elements, which means this can also be animated via CSS (although it's a
> little jumpy right now).
>
> I'm excited to see a proposal that allows more of the SVG attributes to be
> exposed.
>
> Dean
>
>
> On 22/11/2011, at 6:35 AM, Patrick Dengler wrote:
>
> A few weeks ago I signed up to make a proposal for ACTION-3171<http://www.w3.org/Graphics/SVG/WG/track/actions/3171>
> .  Thanks for the early feedback from those I reached out to initially.
> The issues raised and the associated proposed recommendations are
> included.  If a plain-text version is required, I will send a response with
> that. At this point we are looking for feedback as to whether the proposal
> is acceptable, the resolutions are acceptable, and/or there are more issues
> not yet identified.****
>
> Patrick Dengler,****
>
> Microsoft****
>
> CSS Animations and Transitions on SVG Attributes****
>
> *Editors:*
> Patrick Dengler, Microsoft, patd@microsoft.com****
>
> * *
>
> *Contributor Feedback:*
> Erik Dahlström, Opera Software****
> Tab Atkins Jr., Google****
> Cameron McCormack, Mozilla****
> Vincent Hardy, Adobe****
> ** **
>
> Copyright <http://www.w3.org/Consortium/Legal/ipr-notice> © 2011 W3C<http://www.w3.org/>
> ® (MIT <http://www.csail.mit.edu/>, ERCIM <http://www.ercim.eu/>, Keio<http://www.keio.ac.jp/>),
> All Rights Reserved. W3C liability<http://www.w3.org/Consortium/Legal/ipr-notice>
> , trademark <http://www.w3.org/Consortium/Legal/ipr-notice> and document
> use <http://www.w3.org/Consortium/Legal/copyright-documents> rules apply.*
> ***
> *Abstract*
>
> This document describes a proposal for applying CSS Animation and CSS
> Transition effects to values which are currently defined as attributes on
> SVG.  ****
>
> ** **
>
> *Overview
> *CSS Animations and Transitions provide developers a way to animate CSS
> Styles to enhance their web sites and web applications.  This document
> proposes how developers can use these same CSS techniques to address
> animation and transition scenarios to include vector graphics (SVG) in two
> key areas:****
>
> ·         Moving SVG elements: This refers to moving, scaling, rotating
> and otherwise sizing elements****
>
> ·         Animating Filter values : This refers to changing underlying
> mathematic inputs to filters to create dynamic efftects****
>
> ** **
>
> Applying Transitions and Animations to SVG Presentation Attributes<http://www.w3.org/TR/SVG/attindex.html>
>  and SVG Properties is already required<http://www.w3.org/TR/css3-transitions/>
>  in the CSS Animations and Transition specifications. ****
> *Previous Artifacts:*
>
> ·         http://www.w3.org/Graphics<http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation>
> / <http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation>
> *SVG/WG/wiki/F2F/Auckland_2011/CSS_*<http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation>
> *A*<http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation>
> *nimation*<http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation>
> **
>
> ·         *http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_201*<http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation>
> *1*<http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation>
> */CSS_Animation*<http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation>
> **
>
> * *
>
> *Purpose*
>
> This proposal is to “promote” a subset of other SVG Attributes to
> “Presentation Attributes” or “Properties” for the purpose of supporting CSS
> features including transitions and animations.****
> *Problems*
>
> When designing a web site or web application, developers can use CSS on
> properties such as opacity or fill, but do not have access to other
> presentational aspects such as position, size or filter inputs. Animations
> and transitions play a key role in providing those experiences. Web
> Developers benefit greatly from adding rich UI to their experiences to
> differentiate their sites and content from competition.****
> *Value Proposition*
>
> Web Developers can leverage their knowledge of HTML, CSS and JavaScript
> standards to build visually rich Web Applications and Web Sites using CSS3
> Transitions <http://dev.w3.org/csswg/css3-transitions/>  and CSS3
> Animations <http://dev.w3.org/csswg/css3-animations/>.   This value is
> enhanced by expanding Transitions and Animations to include vector graphics
> (SVG).  Non-box model presentation is common in modern user experiences.
> Providing the same animation of color, movement and effects on vector
> graphics enables new scenarios not otherwise available including game
> assets, background other CSS images, and sophisticated advertisements on
> the web.****
> *Landscape*
>
> Other browser such as Mozilla and Chrome support CSS3
> Animations/Transitions on SVG Properties and SVG Presentation Attributes.*
> ***
> *Goals*
>
> ·         Developers can and animate/transition size, scale, rotate and
> position of SVG using CSS               ****
>
> ·         Developers can animate/transition filter effects on SVG (as
> <img> or an inline fragment) OR HTML using CSS****
> *Non Goals*
>
> ·         Animate All Regular Attributes.****
>
> ·         We will identify which specific attributes in SVG should become
> animatable by CSS.        ****
>
> ·         Extend CSS Animations and Transitions to be on par with SMIL
> animations.****
>
> ·         How to Integrate CSS Animations and SMIL****
>
> *Scenarios*
> *Logos and Advertisements*
>
> A designer exports a client’s logo from Illustrator, and instead of
> embedding it on a web page as a GIF image, it can now be embedded at SVG
> and scale up for high DPI monitors. Additionally, instead of using 3rd party
> plug-ins, it can spin and whirl and glow, is accessible, and localizable
> through CSS animations and transitions.****
>
> <image001.jpg>****
>
> *Requirements*: Declarative animations and transitions on filter inputs.**
> **
> *Gaming or Game Title Screens*
>
> A premiere Web and Web Application scenario is casual gaming. Causal
> gaming often includes raster images/sprits and/or SVG images or fragments.
> Selection effects on graphic menus or animations on game pieces can also be
> added through transitions and animations on shapes, positions or filters on
> these assets.****
> *Background Effects*
>
> Rich graphic experiences on the Web mean fewer static experiences.  This
> could be from subtle background themes with light, animated filter effects
> or full scene animations.****
>
> ** **
>
> <image002.jpg>****
>
> *Requirements*: Declarative animations on filter inputs and position/size
> of geometries.****
> *Queues and Triggers on UI*
>
> Modern user experiences indicate to users when things happen and how to
> make things happen using triggers and queues.  Since UI is no longer
> rectangular, transitions on vector graphics are just as important.****
>
> ** **
>
> <image003.png>****
>
> (Transform offset with filter attribute shift)****
>
> Whether a queue (a transitioned glow and/or transitioned position) on the
> graphic that a new UI element is available, or a transition that occurs
> such as an opacity or color shift triggered off a user gesture, these
> experiences have been proven beneficial to a user’s comprehension of how an
> interface works, and needs to expand beyond boxes and lines.****
>
> *Requirements*: Transitions on position and size of geometries.****
>
> *The Proposal*
>
> Continue to support the transitions and animations on SVG Properties and
> SVG Presentation Attributes enables as specified.  Promote additionally
> useful attributes topresentation attributes<http://www.w3.org/TR/SVG/styling.html>
>  as described by the current SVG Specification.****
>
> For each styling property defined in this specification (see Property
> Index <http://www.w3.org/TR/SVG/propidx.html>), there is a corresponding
> XML attribute (the presentation attribute) with the same name that is
> available on all relevant SVG elements. For example, SVG has a ‘fill’<http://www.w3.org/TR/SVG/painting.html>
>  property that defines how to paint the interior of a shape. There is a
> corresponding presentation attribute with the same name (i.e., ‘fill’) that
> can be used to specify a value for the ‘fill’<http://www.w3.org/TR/SVG/painting.html>
>  property on a given element.****
>
> ** **
>
> Allow styling of these new presentation attributes and make them available
> to CSS and thus animations and transitions.****
> *Applying Transition and Animations to SVG*
>
> This section is provided as background and to provide and understanding of
> why a developer would want the attribute promotion model proposed here.
> Note: This functionality is supported in some browsers today.****
>
> Applying Transitions and Animations to SVG Properties is already described
> in the CSS Animations and Transitions specification.  An example of
> transition the CSS opacity property attribute over 5 seconds is illustrated
> with the code below:****
>
> ** **
>   circle { opacity:.1; -ms-transition-property: opacity;
> -ms-transition-duration: 5s; }****
>   circle:hover {opacity:1; }****
> ** **
>
> ** **
>
> Presentation Attributes (such as fill ) are also supported:****
>    circle { fill:red; -ms-transition-property: fill;
> -ms-transition-duration: 5s; }****
>    circle.hover { fill:blue;}****
>
> ** **
>
> This proposal simply adds to the list of presentation properties, such as
> x and y in the example below.  Developers can and will expect use the
> attributes identified in this specifications with animations, transitions
> and holistically as styles.  (The examples included below are also provided
> in the prototype code supplied.  Currently the prototype code only
> currently works on IE10).****
> .positional****
> {****
>     x: 100px;****
>     y: 100px;****
>    ****
>     -ms-animation-name: msPositional;****
>     -ms-animation-duration: 5s;****
>     -ms-animation-iteration-count: infinite;****
>     -ms-animation-timing-function: linear;****
> ** **
> }****
> ** **
> @-ms-keyframes msPositional****
> {****
>     from { x: 100px; y: 100px; fill:green;}****
>     to { x: 200px; y: 300px;  fill:red;}****
>     }****
> }****
> ** **
> .wobble****
> {****
>     cx: 100px;****
>     r:10px;****
>     stroke-width:10px;****
>     stroke:black;****
>     -ms-animation-name: msWobble;****
>     -ms-animation-duration: 2s;****
>     -ms-animation-iteration-count: infinite;****
>     -ms-animation-timing-function: linear;****
> }****
> ** **
> ** **
> @-ms-keyframes msWobble {****
> ** **
>     0% { cx: 500px; r:10px; stroke-width:2px;  }****
>     40% { cx: 750px; r:15px; stroke-width:5px; }****
>     60% { cx: 375px; r:20px; stroke-width:10px; }****
>     100% { cx: 500px; r:30px; stroke-width:1px; }****
> }****
> ** **
>
> *Details*
> *Definitions*
>
> The definitions and proposed solution for some of issues (and potential
> future issues) are provided here.****
>
> *Semantic and Type Collision* – Semantic Collision is when there is an
> existing style already defined in CSS with the same name as an attribute in
> SVG but has different meaning. ****
>
> Proposal: Do nothing. It is not necessary to change anything if there are
> simply semantic differences.****
>
> *Example*
>
> azimuth for Aural stylesheets accepts unit type:****
>
> *Current CSS:*
>
> *'azimuth'*****
>
> *Value:*****
>
> <angle> | [[ left-side | far-left | left | center-left | center |
> center-right | right | far-right | right-side ] || behind ] | leftwards |
> rightwards | inherit****
>
> *Current SVG:*
> azimuth = "*<number>*<http://www.w3.org/TR/SVG11/types.html#DataTypeNumber>
> "****
>
> ** **
>
> Azimuth for SVG filter support float ****
>
> *Type Collision* – Type Collision occurs when there exists an existing
> style already defined in CSS with the same name as an attribute in SVG
> different but has a different or additional value type, independent of any
> semantic differences.  This can also occur when there is a semantic
> collision.****
>
> Proposal: Add that unit type to the CSS Property.  Follow the already
> identified rules when unit types do not apply to a specific element.****
>
> *Element Collision* – In SVG, attributes with the same name sometimes
> have different unit types.****
>
> Proposal: Follow the same solution as type collision. Add that unit type
> to the new proposed CSS Property.  Follow the already identified rules when
> value types do not apply to a specific element.****
>
> In cases where a <number> is expressed in both CSS and SVG, see issue #6
> below.****
>
> ** **
>
> *The Attributes*
>
> The following is a list of attributes which this document proposes we
> promote to properties.  See issue #8 below for the reasoning behind this
> reduced set.****
> *Table of Proposed Attributes*
> Attribute****
> Issues****
> amplitude****
> ** **
> azimuth****
> Semantic and Type Collision w/ CSS a<http://www.w3.org/TR/2008/REC-CSS2-20080411/aural.html>
> ural  <http://www.w3.org/TR/2008/REC-CSS2-20080411/aural.html>azimuth <http://www.w3.org/TR/2008/REC-CSS2-20080411/aural.html>
> Property <http://www.w3.org/TR/2008/REC-CSS2-20080411/aural.html>.****
> Recommendation: Follow general proposal and add support for type<<http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html>
> number <http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html>><http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html>
>  to azimuth. ****
> baseFrequency****
> ** **
> bias****
> ** **
> cx,cy****
> ** **
> diffuseConstant****
> ** **
> divisor****
> ** **
> dx****
> ** **
> dy****
> ** **
> elevation****
> Semantic and Type Collision w/ CSS aural e<http://www.w3.org/TR/2008/REC-CSS2-20080411/aural.html>levation
> property <http://www.w3.org/TR/2008/REC-CSS2-20080411/aural.html>.****
> Recommendation: Add support for type <<http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html>
> number <http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html>><http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html>
>  to azimuth. ****
> exponent****
> ** **
> fx****
> ** **
> fy****
> ** **
> height, width****
> ** **
> intercept****
> ** **
> k1,k2,k3,k4****
> ** **
> limitingConeAngle****
> ** **
> numOctaves****
> ** **
> offset****
> Element Collision (gradient and filter).****
> Recommendation: Follow the Element Collision model****
> pointsAtX,pointsAtY, pointsAtZ****
> ** **
> r****
> ** **
> radius****
> ** **
> rx,ry****
> ** **
> scale****
> ** **
> specularConstant****
> ** **
> specularExponent****
> ** **
> startOffset****
> ** **
> stdDeviation****
> ** **
> surfaceScale****
> ** **
> targetX,targetY****
> ** **
> transform****
> Larger issue being covered with a separate specification to rationalize
> CSS and SVG Transforms both 2D and 3D. ****
> x,y****
> ** **
> x1,x2,y1,y2****
> ** **
> z****
> ** **
>
> ** **
>
> *Issues*
>
> (The following issues have been identified by the working group thus far.
> The first 5 issues are practically verbatim from Cameron McCormack’s follow
> up to the original proposal).**
>
> *Issue #1*: CSS has existing properties for defining the extent of CSS
> boxes: top, left, width, and height. An SVG rect has x, y, width, height.
> Do top and left have any significance? It may be confusing to use different
> properties.****
>
> *Proposed Resolution:** Resolving x,y or cx, cy vs. top and left are not
> germane to this effort and should be addressed separately if it is
> determined that an attribute overhaul is necessary for SVG. For this
> proposal, we would preserve x,y,cx,cy et.al. as they are currently named.*
> ****
>
> *Issue #2*: Currently in SVG, there are slightly different rules as to
> what is allowed in presentation attributes compared to those in a style
> sheet. This is what results in scientific notation being allowed in the
> 'stroke-width' presentation attribute but disallowed when stroke-width is
> specified in the 'style' attribute. We would need to be mindful that the
> syntax for attributes we promote fits in with the CSS parser.****
>
> *Proposed Resolution:** For scientific notation and similar, we just keep
> rules about the different parsing of presentation attributes versus
> property values in style sheets. For syntax fitting in with the grammar,
> there don’t seem to be any values which would cause problems.*****
>
> *Issue #3*: This proposal changes the current distinction between
> attributes and properties in the language. In HTML, the division of HTML
> attributes and CSS properties is the semantics/styling one. In SVG, some
> think of CSS support as more fundamental to the semantics of the document:
> that a shape has a particular size or dimension is probably semantically
> important, but also its color will be. That might not have been the view of
> the original authors of the SVG specification. It has been said that SVG is
> only content. ****
>
> *Proposed Resolution:** By preserving the Presentation Attribute model,
> the author can disambiguate this semantic from presentational aspects of
> the document by maintaining content in attributes separate out, as desired,
> styling. So the geometry of an element may not need to be a particular
> value to convey the semantics of the document – instead it might just be a
> visual effect for aesthetics. It is currently not always possible to
> correctly divide semantics and style between the XML and CSS anyway. Thus,
> if maintaining this distinction between semantics and styling is useful,
> promoting some attributes to properties gives more flexibility to the
> author to declare which aspects of a document are semantically important
> and which are stylistic choices.*****
>
> *Issue #4**:* Do we choose a set of attributes to promote to properties,
> and if so, what is that set? The set of animatable SVG attributes would be
> a good starting point.****
>
> *Proposed Resolution:** In the spirit of use case driven specifications
> and incremental deliverables, this proposal defines that subset of
> interesting attributes.*
>
> *Issue #5*: In CSS, properties have global meaning/syntax across
> elements. SVG attributes can have different meanings. For example x on text
> takes a list of lengths, while it takes only a single value on rect.****
>
> *Proposed Resolution:** Rules to address Semantic Collision, Type
> Collision and Element Collision are provided in this specification.*
>
> Response to Proposed Resolution: These are both problematic.  There
> *aren't* identified rules for what to do when unit types don't apply to a
> particular element.  Specific properties do this with specific keywords
> ("treat XXX like YYY when ZZZ"), and the flex() notation for flexbox has a
> special treatment in non-flex situations, but these are (1) special-cased
> each time, and****
>
> (2) handled such that they always become a valid (and as much as possible,
> reasonable) value.****
>
> ** **
>
> I don't see how you can handle (2) generally.  You can't just say "whoops,
> you can't use a percentage for the 'offset' property on filter elements!",
> because what does that mean?  This isn't a parse-error - you don't know
> what the element is until at least specified-value time - so you can't just
> drop the rule and use one lower in the cascade.  You've got an invalid
> value and nothing to fall back to.  I handle this in Variables, because
> there is literally no way to avoid it, but this *can* be avoided here.****
>
> ** **
>
> ** **
>
> I think a better idea would be to deal with Type and Element collisions by
> creating a property with a new name, rather than just sticking with the
> exact same name as the attribute.****
>
> ** **
>
> *Issue #6**: CSS does not support unitleses types for properties that are
> already defined and have units unless the page is in quirks mode. ***
> *Proposed Resolution**: Values without unit types are currently supported
> (such as opacity). Properties that are always float (such as inputs to
> Fiters) will not require unit type. Shared properties or new properties
> that are not simple floats and can have unit types will require unit types
> for SVG when used in a style sheet.*
> * *
> *Alternate Proposal:** An alternate proposal has been that a unit type
> designator ( ‘n’, ‘f’) be added to the CSS specification to represent
> numbers or float.*
> * *
> *Issue #7:*  In the case of Element Collision, sometimes a rule for
> example of { dx: 5; dx: 1 2; } will result in a different value for dx
> depending on the element to which it is applied. ****
> ** **
> *Proposed Resolution*: Apply the style on a per element basis accepting
> the general rules of CSS. If “1 2” is applied to a property where “1 2”
> cannot be applied, follow the standard error handling. ****
> ** **
> *Issue #8* : The list of attributes to promote seems somewhat arbitrary.**
> **
> ** **
> *Proposed Resolution*: Several arguments have been made about which
> attributes to promote and which attributes should remain as attributes.
> There is no intentional implication of always having the promotion idea
> constrained to this subset. ****
> ** **
> The desire is to solve, as much as possible, the key scenarios identified
> in this document. Declarative animation can be complicated and has been
> well established in several specifications include SMIL for SVG. While
> investments continue to be made in the CSS Animations specifications, the
> inclusion of these proposed properties expands the scenarios for SVG short
> term.  Animations and/or tranisitons on attributes such a
> gradientTransform or d are and can be useful, but not necessary to
> resolve some short term scenarios and avoids some of the longer term
> discussions about what it means to introduce and interpolate over new types.
> ****
>
> ** **
>
> ** **
>
> *Acknowledgments*
> Cameron McCormack, Software Engineer at Mozilla Corporation for the
> original write up of the three distinct proposals and their pros and cons.
> ****
>
> Jennifer Yu, Program Manager at Microsoft for a detailed review.****
>
> *Change Log*
>
> *References*
>
> *SVG1.1 2nd Edition*
>
> Erik Dahlström, et. al*. *Scalable Vector Graphics (SVG) 1.1 (Second
> Edition) <http://www.w3.org/TR/SVG/> 16 August 2011. W3C**
>
> *CSS21*
>
> Bert Bos; et al. *Cascading Style Sheets Level 2 Revision 1 (CSS 2.1)
> Specification.* <http://www.w3.org/TR/2011/REC-CSS2-20110607> 7 June
> 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-CSS2-20110607
> ****
>
> *CSS3-Transitions*
>
> Dean Jackson; et al. *CSS Transitions Module Level 3.*<http://www.w3.org/TR/2009/WD-css3-transitions-20091201>
>  1 December 2009. W3C Working Draft. (Work in progress.) URL:
> http://www.w3.org/TR/2009/WD-css3-transitions-20091201****
>
> *CSS3-Animations*
>
> Dean Jackson; et al. *CSS * <http://www.w3.org/TR/css3-animations/>*
> Animations * <http://www.w3.org/TR/css3-animations/>Module Level 3.<http://www.w3.org/TR/css3-animations/>
>  20 December 2009. W3C Working Draft.****
>
> ** **
>
> ** **
>
>
>