Jonathan Watt wrote:
> But what if you go against these
> instructions? What if you use createElement instead of createElementNS in
> your SVG documents? What should happen? Is it possible that it could create
> an element in the same namespace as the element you called it on? Well yes.
> Probably it is. The specifications don't say what the namespace ignorant
> methods should do. That's why it says not to use them. (Probably the DOM WG
> when discussing what should happen couldn't come to an agreement, so they
> left it unspecified, making it possible to get into the mess we find
> ourselves in now.)
[sfx: coughing bordering on choking]
From the DOM 3 Core spec: "A new Element object with the nodeName
attribute set to tagName, and localName, prefix, and namespaceURI set to
null." That's what createElement() returns. For setAttribute() things
are less directly limpid, but it still says "To set an attribute with a
qualified name and namespace URI, use the setAttributeNS method".
So no, it's not possible that this would happen. What /is/ possible is
that by mixing both NS-aware and NS-unaware methods you create a DOM
that is extremely hard to serialize (it might be possible to make it
impossible) and therefore if you save it to XML and then load it back
some elements will have different namespaces.
But that would be daft.
> The problem is, browsers (such as Mozilla) decided long
> ago to make a consistant stand. If namespace ignorant methods don't know
> about namespaces, then they don't set a namespace. As far as I can tell this
> is the rule that has been followed. At least until ASV came along. Due to
> their lack of knowledge of the browser world, it seemed Adobe decided to do
> the opposite, and hence our current problem.
It's not even the browser world, the specs were broken. It's a pity,
aye, but ASV is waning fast as Firefox rises so soon enough those broken
bits should be forgotten about.
> A lot of us have a considerable amount of SVG written without proper
> attention to namespaces. Couldn't browsers change to implement your
> proposal? Well maybe they could.
No, they couldn't. It would not only violate the specs, it would also
likely break content. I have pre-SVG 1.0 (IIRC it was ASV 2.0?) content
that uses multiple namespaces intensively, and I'm sure I'm not the only
one.
> But right now they have a consistant
> policy. If they were to change it, it would be best to change it for all
> XML, not just SVG.
In fact you couldn't change it just for SVG, since the point is that you
may be writing stuff from another namespace :)
> In short my advice would be to accept that namespaces and current behaviour
> in the wider XML world is not going away. Spend a little time getting your
> head the safe and portable way to do things and use the namespace aware
> methods whenever you write XML. It's the only way to ensure your scripts
> will work cross-implementation. If you're really serious about your
> proposal, then take it up with the SVG WG.
No, please don't. Namespaces are not changing. The Core DOM is not
changing. And thankfully the SVG WG is not in control of the Core DOM,
we've got enough on our plates already.
Namespaces don't have to be a pain. Doug sent in a small thing to set
attributes and create elements, there are zillions of other options.
Find the one that you like. Everyone hates the DOM, but everyone hates
it for different reasons. There's no way we're going to get something
that'll please all users, so all that can be done is something correct,
that works, and that people can build their own APIs on top of.
It's easy too. Off the top of my head, the following will create an
element with a bunch of attributes:
function createSVGElement (name, attr) {
var el = document.createElementNS(svgNS, name);
for (n in attr) {
var ns = n == "xlink:href" ? xlinkNS : null;
el.setAttributeNS(ns, n, attr[n]);
}
return el;
}
You call that as:
var myRect = createSVGElement("rect", {width:10,height:5,fill:"red"});
(where the list of attributes can be pretty much anything). Your myRect
is a full blown element, add it to the tree and you'll get a small red
rectangle in the top left corner.
How easy does it get? What are people complaining about? Why ask that
highly infrastructural standards to change when you can stop, think for
half a second, and come up with a seven line solution?
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/1U_rlB/TM
--------------------------------------------------------------------~->
-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
