W3C home > Mailing lists > Public > www-svg@w3.org > November 2013

Re: Improving SVG DOM: Modification request

From: Brian Birtles <bbirtles@mozilla.com>
Date: Mon, 25 Nov 2013 10:19:15 +0900
Message-ID: <5292A593.1060602@mozilla.com>
To: www-svg@w3.org
Hi Dirk,

A couple of brief thoughts here:

(2013/11/21 0:56), Dirk Schulze wrote:
> ...
> I would like to suggest some modifications to the original proposal that makes it much more compatible to the current SVG DOM and backwards compatible to todays SVG implementations for the most part. Current implementations would not break on supporting basic functionality that is already in SVG today. Some of the modifications already exist as issues in the original proposal itself:
> * Remove SVG namespace. Elements or attributes explicitly created with SVG namespace will still end up with no namespace. Keep current object names (SVGNameElement)

I think backwards compatibility is a concern here. namespaceURI is often 
used to differentiate SVG elements from others. e.g. [1]

If we can ensure all the differences between SVG elements and HTML 
elements are removed at the same time then it might work. For example:
  - Make sure the xlink namespace is not needed for href (done)
  - Make className no longer a DOMAnimatedValue
  - Make sure 'classList', 'children' etc. are supported on SVG elements
  etc. etc.

> * use unions to give some attributes a new meaning for an potentially new SVG DOM

Can you explain this?

I think, for example,

   interface SVGRectElement : ... {
     attribute (SVGAnimatedLength or float or DOMString) x;

would be quite difficult for authors to deal with. Given a rect element 
passed into a function you would have to test the type of every property 
before using it wouldn't you?

I think Cameron had two suggestions here:

interface SVG2RectElement : ... {
   attribute (float or DOMString) x;


interface SVG2RectElement : ... {
   attribute float x;
(with setAttribute if you want to set a string)

We've come across this problem in Web Animations too where you want the 
numerical property for convenience and the string for flexibility. 
Perhaps we need a platform convention here?

Best regards,


Received on Monday, 25 November 2013 01:19:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:47 UTC