CSS Animation and Transitions on SVG attributes

Hello www-style,

the SVG WG (along with the FX taskforce) seeks feedback on the following proposal:

     http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html

The summary of the proposal is that a subset of the SVG attributes will be promoted to CSS properties.

Some examples using the proposed syntax:

     http://dev.w3.org/SVG/proposals/css-animation/examples/default.html


The already identified issues from the proposal document are repeated below for easier commenting:

* Do these new properties need to be prefixed (e.g 'svg-x') to deal with possible collisions?

* 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 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.

* Issue #6:
   CSS does not support unitless 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 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.

   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 (can be considered addressed if the proposed resolution for issue #5 is accepted):
   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.

* 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.


Thanks
-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 7 February 2012 12:34:00 UTC