Re: CSS Animations and Transitions on SVG Attributes

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.  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 © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use 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 and SVG Properties is already required in the CSS Animations and Transition specifications. 
> 
> Previous Artifacts:
> ·         http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/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  and 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 as described by the current SVG Specification.
> 
> For each styling property defined in this specification (see Property Index), 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’ 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’ 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>"
>  
> 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 aural azimuth Property.
> Recommendation: Follow general proposal and add support for type<number> to azimuth. 
> baseFrequency
>  
> bias
>  
> cx,cy
>  
> diffuseConstant
>  
> divisor
>  
> dx
>  
> dy
>  
> elevation
> Semantic and Type Collision w/ CSS aural elevation property.
> Recommendation: Add support for type <number> 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) 16 August 2011. W3C
> 
> CSS21
> 
> Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 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. 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 Animations Module Level 3. 20 December 2009. W3C Working Draft.
> 
>  
> 
>  
> 
>