- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 1 Dec 2009 12:16:23 +0100
- To: Doug Schepers <schepers@w3.org>
- Cc: Jeff Schiller <codedread@gmail.com>, www-svg <www-svg@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 UTC