- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 29 Apr 2013 08:46:59 +0200
- To: "Dirk Schulze" <dschulze@adobe.com>
- Cc: "www-svg@w3.org" <www-svg@w3.org>
On Fri, 26 Apr 2013 16:12:04 +0200, Dirk Schulze <dschulze@adobe.com> wrote: > > On Apr 26, 2013, at 6:29 AM, Simon Pieters <simonp@opera.com> wrote: > >> Hi >> >> The DOM spec defines the id and className (and classList) on Element. >> >> http://dom.spec.whatwg.org/#interface-element >> >> HTML has dropped these, relying on DOM. Maybe SVG should do the same? >> >> This has come up before but the SVG spec hasn't changed (well the TR >> version, the editor's draft doesn't have the IDL), so I guess nothing >> has >> been concluded yet? > > The definition on SVG is: > > readonly attribute SVGAnimatedString className; > > As mentioned in the referenced mailing list discussion, the problem is > the SVGAnimation representation. From an implementation point of view I > am very much in favor for this change. At least in WebKit and in Blink > this could cleanup the source code a lot. The main difficulty is that > SVGAnimations on class were not deprecated in SVG1.1SE. I am a bit > scared to remove it from the specification (and replace it with the > Element definition) without notice. If content does not depend on className being SVGAnimatedString, we can go ahead and make the change in the spec and in implementations. If content does depend on className being SVGAnimatedString, we're stuck with it. In my opinion it is of little importance whether SVG1.1SE deprecated it or not. Having a "deprecation" period in the spec just means that the old API will be supported in implementations longer and thus more likely that Web content ends up depending on it, which reduces the likelihood that we can make the change in the future. If we think that a change should be made and it can be made, it should be made ASAP, IMHO. -- Simon Pieters Opera Software
Received on Monday, 29 April 2013 06:47:30 UTC