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
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'
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
|
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,cy
|
|
|
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,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.
SVG Working
Group Agrees with the above resolution
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.
SVG Working Group has already addressed this in SVG
2.0
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.
SVG Working
Group Agrees with the above resolution
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.
SVG Working
Group Agrees with the above resolution
Issue #5: 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 FX
members.
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.
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.
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.
This is now
addressed in issue #5 as stated by the SVG Working Group.
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.
The
SVG Working Group has agreed with this resolution.
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.
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.
Requirements: Declarative animations on filter inputs and position/size of
geometries.
Cues 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.
(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.
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
1.26.2012
Updating with feedback from SVG Working Group at Auckland
Face to Face.
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.