W3C home > Mailing lists > Public > www-svg@w3.org > December 2009

Re: More Ideas around DOM Constructors

From: Robin Berjon <robin@berjon.com>
Date: Tue, 1 Dec 2009 12:16:23 +0100
Cc: Jeff Schiller <codedread@gmail.com>, www-svg <www-svg@w3.org>
Message-Id: <4863C013-BDBA-4BBB-A70C-76C0F66319CA@berjon.com>
To: Doug Schepers <schepers@w3.org>
Hey,

On Nov 27, 2009, at 08:28 , Doug Schepers wrote:
> My approach was similar, but didn't rely on a QName-syle approach because of some brittleness there.  Here's how I did it [1]:
> 
> root.createElement( "use", { href:[ xlinkns, "#my_circle" ], x:30, y:"-30" } );

It doesn't have to be brittle if it's well specified! You could easily state that "xlink" and "xml" are well-known prefixes that are pre-defined. That has the bonus of eliminating the more common uses (having implemented that, I find that it works nicely).

Your above example could hit a bit of a problem:

  root.createElement("use", { href: [XLINK_NS, "#a"], href: [XHTML_NS, "#b"] });

So you need to enable using a prefix in the object. I think that it gets annoying quickly as you start working out the details, and more importantly that it breeds confusion.

I'd say go radical:

  root.addNS("uni", "http://unicorns-galore.org/ns/pink");
  ...
  root.createElement("path", { "uni:opacity": "none" });

Yes it means that libraries intending to use namespaces have to be smart to not walk on one another's feet. I think that's an acceptable issue given that libraries can be fixed easily, at little cost, and are maintained by people who will understand the issue.

> I would like to move away from the use of the XLink NS, since the promise of the XLink spec never really materialized.  There are complications, but I think we can do it.

Yes, it really should go away :)

-- 
Robin Berjon - http://berjon.com/
Received on Tuesday, 1 December 2009 11:16:53 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT