- From: Dirk Schulze <vbs85@gmx.de>
- Date: Fri, 21 Oct 2011 21:51:44 +0200
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Rick <graham.rick@gmail.com>, www-svg <www-svg@w3.org>
Am 21.10.2011 um 21:22 schrieb Cameron McCormack: > On 21/10/11 3:06 PM, Dirk Schulze wrote: >> If we think about renaming SVG Objects in the SVG DOM, we could >> rethink the complete concept of SVG DOM. I'd love to replace some SVG >> Objects / Unit types by corresponding CSS Object / units like >> SVGMatrix, SVGLength, SVGTransform and so on. They were useful in the >> past, but CSS improved a lot in the meantime and can take >> functionality over. That would also help supporting CSS Transitions / >> Animations with several SVG attributes. But it would definitely break >> backward compatibility! Every renaming would break backward >> compatibility! > > I am not convinced that all renamings we could possibly do would break backward compatibility. Renaming SVGPathSegCurveToQuadraticAbs? I would be very surprised if anyone was messing with SVGPathSegCurveToQuadraticAbs.prototype, for example. We had (and still have :() some bug reports regarding SVGPathSegList. Many examples made use of these objects. I expect that a lot more examples are out there than we expect. > > As part of improving the SVG DOM -- and I do think we should try to do this -- maybe renaming is not the answer, but introducing parallel, more useful and usable APIs. Sure, we can introduce additional APIs. And if we want to guarantee backward compatibility we can only go this way. Even if I would like to harmonize SVG DOM more with the new CSS improvements. > >>>> var p = new SVGPathElement( string ); >> That would work. But don't we support it anyway by setting the 'd' >> attribute via normal DOM? > > Yes, so it would just be a (slight) convenience. Maybe unnecessary with the proposed DOM Core improvements being discussed on public-webapps/www-dom.
Received on Friday, 21 October 2011 19:52:23 UTC