Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes a proposal for applying CSS Animation and CSS Transition effects to values which are currently defined as attributes on SVG.
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:
Applying Transitions and Animations to SVG Presentation Attributes and SVG Properties is already required in the CSS3 Animations and CSS3 Transition specifications.
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.
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.
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.
Other browsers such as Mozilla and Chrome support CSS3 Animations/Transitions on SVG Properties and SVG Presentation Attributes.
Continue to support the transitions and animations on SVG Properties and SVG Presentation Attributes enables as specified. Promote additionally useful attributes to presentation attributes as described by SVG 1.1 Second Edition:
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.
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; }
}
The definitions and proposed solution for some of issues (and potential future issues) are provided here.
Proposal: Do nothing. It is not necessary to change anything if there are simply semantic differences.
Example:
The 'azimuth' property for Aural stylesheets accepts unit type.
Current CSS definition of the 'azimuth' property:
Current SVG definition of the 'azimuth' attribute:
Proposal: Add that unit type to the CSS Property. Follow the already identified rules when unit types do not apply to a specific element.
Proposal: Follow the same solution as for 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 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.
| Attribute | Issues |
|---|---|
| amplitude | |
| azimuth | Both azimuth and elevation were a part of CSS Aural style sheets. It was recommended that these could be deprecated and we should close that with the CSS Working Group. |
| baseFrequency | |
| bias | |
| cx | |
| cx | |
| diffuseConstant | |
| divisor | |
| dx | |
| dy | |
| elevation | Both azimuth and elevation were a part of CSS Aural style sheets. It was recommended that these could be deprecated and we should close that with the CSS Working Group. |
| exponent | |
| fx | |
| fy | |
| height, width | |
| intercept | |
| k1 | |
| k2 | |
| k3 | |
| k4 | |
| limitingConeAngle | |
| numOctaves | |
| offset | |
| 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 | |
| x1 | |
| x2 | |
| y | |
| y1 | |
| y2 | |
| z |
The following issues have been identified by the SVG working group thus far. The first 5 issues are practically verbatim from Cameron McCormack’s follow up to the original proposal.
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.
SVG Working Group Agrees with the above resolution.
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.
SVG Working Group has already addressed this in SVG 2.0.
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.
SVG Working Group Agrees with the above resolution.
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.
SVG Working Group Agrees with the above resolution.
In CSS, properties have global meaning/syntax across elements. SVG attributes can have different meanings and take slightly different types. For example x on text takes a list of lengths, while it takes only a single value on rect.
Proposed Resolution: If the types are different enough, we will identify a new name. This proposal is specifically limited such that this does not happen. In the case of a property with a new name, rather than just sticking with the exact same name as the attribute. In the case of the list where x can take a list of lengths, though we don't get this for free from CSS, but we just need explicit wording to say what happens when you do <rect style="x: 10px 20px">, which is fine.
This resolution came out of a further discussion with the SVG Working Group and some SVG/CSS FXTF members.
Proposed Resolution: Values without unit types are currently supported (such as opacity). Properties that are always float (such as inputs to Filters ) 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.
SVG Working Group Agrees with the above resolution.
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.
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.
This is now addressed in issue #5 as stated by the SVG Working Group.
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.
The SVG Working Group has agreed with this resolution.
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 3 rd party plug-ins, it can spin and whirl and glow, is accessible, and localizable through CSS animations and transitions.
Requirements: Declarative animations and transitions on filter inputs.
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.
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.
Requirements : Declarative animations on filter inputs and position/size of geometries.
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.
(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.
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.
31 January 2012
Cleaned up markup, discarding the Word-generated original entirely. Added some links and corrected typos.
26 January 2012
Updating with feedback from SVG Working Group at Auckland Face to Face.