RE: CSS Animation and Transitions on SVG attributes

Hi folks,

I have not seen any more responses to this thread (perhaps I missed them?).  We identified this as a high priority issue in August of 2010 and we have been discussing in the SVG/CSS FX task force for well over a year. We collectively made the resolution to address this issue with the CSS/SVG FX task force at TPAC in 2010; I was asked to write it up more recently and would like to close if this is possible.
This proposal was the resolution reached by the SVG Working Group at the last face-to-face at the end of last year.  Many of the members of the CSS working group have been a part of the discussion. The same issues keep arising and we tend to eventually land on the same resolutions.  I ask you as graciously as I can that we either find new issues, choose different resolutions or resolve this.  I'm not married to any one direction but do believe after owning this for so long, that this is the right thing to do.

What are the appropriate steps to reach resolution?

Thanks in advance,

Patrick

----


Hi Simon and Dirk,



Thanks for responding. The issue Simon raises was considered many times; as Dirk notes there a pros and cons to both.  My position is that if a developer doesn't know what 'r' is, for example, then they wouldn't encounter it first or only in their CSS, they would likely see <circle> in their HTML.  Either way, if they are using circles, r, x or any of these concepts, they are going to need to learn them.  I personally don't think we should make decisions one way or another just because people are still unfamiliar with it.



( to extract the issue so others don't have to chase links, I have included the resolution we reached within SVG below)



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





And



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





From: Dirk Schulze [mailto:dschulze@adobe.com<mailto:dschulze@adobe.com?Subject=RE%3A%20CSS%20Animation%20and%20Transitions%20on%20SVG%20attributes&In-Reply-To=%253CD7C8ABF3132F9D439385C55C1955D82DE9B5E3%40TK5EX14MBXC293.redmond.corp.microsoft.com%253E&References=%253CD7C8ABF3132F9D439385C55C1955D82DE9B5E3%40TK5EX14MBXC293.redmond.corp.microsoft.com%253E>]

Sent: Tuesday, February 21, 2012 10:29 AM

To: Simon Fraser

Cc: Patrick Dengler; www-style@w3.org<mailto:www-style@w3.org?Subject=RE%3A%20CSS%20Animation%20and%20Transitions%20on%20SVG%20attributes&In-Reply-To=%253CD7C8ABF3132F9D439385C55C1955D82DE9B5E3%40TK5EX14MBXC293.redmond.corp.microsoft.com%253E&References=%253CD7C8ABF3132F9D439385C55C1955D82DE9B5E3%40TK5EX14MBXC293.redmond.corp.microsoft.com%253E>

Subject: Re: CSS Animation and Transitions on SVG attributes



Hi,



while I don't have strong objection on adding prefixed versions of SVG properties. But there are still things to consider.



1) We already have unprefixed just SVG CSS properties like: fill, stroke, clip-path, mask.... So it might be strange to deal with unprefixed and prefixed SVG-CSS properties.



2) Some properties would have the same meaning on standard CSS as well as SVG CSS like 'with' or 'height'. Why should we add new properties for them?



Other properties might sound the same but have quite different meanings, which is bad as well.



Greetings;

Dirk





On Feb 21, 2012, at 10:10 AM, Simon Fraser wrote:





The point being that potentially these all end up as properties in CSS?



I strongly think they should get prefixed, for two reasons:

1. Avoiding conflict with existing and future CSS properties.

2. Making CSS easier to understand; if I were reading some random CSS file and stumbled across a property called 'r', I'd b e scratching my head and wondering what the heck it meant. 'svg-r' would help.



Simon



On Feb 21, 2012, at 8:56 AM, Patrick Dengler wrote:





Hi folks,



I wanted to ping one more time about the list of issued identified in creating the proposal for CSS Animations on SVG.  The the issues and proposed recommendations are listed in this text sent out on Feb 7th. I wasn't sure if it was lost in the shuffle or just simple (cross my fingers) well thought out and acceptable :).  I believe Erik and Chris have also tried to get some response.  In either event, it would be great to see if we can close on this, or whether we need more issues to resolve.  In the meantime, I am going to make the edits to the SVG Specification.



-Patrick Dengler

Microsoft





RE: http://lists.w3.org/Archives/Public/www-style/2012Feb/0333.html















I was responsible for providing the list of presentation attributes that the SVG Working Group has resolved to be the proposed set for inclusion in CSS Animations.  This list is included here:







amplitude



azimuth



bias



cx,cy



diffuseConstant



divisor



dx



dy



elevation



exponent



fx



fy



height,width



intercept



k1,k2,k3,k4



limitingConeAngle



numOctaves



offset



pointsAtX,pointsAtY, pointsAtZ



r



radius



rx,ry



scale



slope



specularConstant



specularExponent



startOffset



stdDeviation



surfaceScale



targetX,targetY



transform



x,y



x1,x2,y1,y2



z