- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 21 Nov 2011 12:13:54 -0800
- To: Patrick Dengler <patd@microsoft.com>
- Cc: FX <public-fx@w3.org>
- Message-ID: <CAGN7qDBGZ6Ks2a1Y0NUvhqkGqnSUpgNO2DAZixtrqTHCjoct3g@mail.gmail.com>
Hi Patrick, very nice! I assume you will remove the '-ms' prefixes in the official proposal? :-) Rik On Mon, Nov 21, 2011 at 11:35 AM, Patrick Dengler <patd@microsoft.com>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 3rdparty 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.**** > > *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.**** > > ** ** > > **** > > (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 to presentation 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. > **** > > ** ** > > ** ** > > ** ** >
Attachments
- image/jpeg attachment: image001.jpg
- image/jpeg attachment: image002.jpg
- image/png attachment: image003.png
Received on Monday, 21 November 2011 20:14:45 UTC