On 10/6/05, Richard Smith <[EMAIL PROTECTED]> wrote: > > <<why setAttribute(attr,prop) does not default > to setAttributeNS(CurrentDocNS,attr,prop) ??? > JD>> > > Indeed (and the same with createElement). I don't think he was suggesting > that setAttributeNS() should be removed, but it is silly that there is a > setAttribute() which we currently can't use! It would make much more sense > if the setAttribute() and createElement() functions just 'worked' - i.e. > created things in the default namespace of the document. (I.e., the one > specified by the xmlns="blaah" in the root node.) >
I think this particular question is a valid one, so I'd like to contribute here. First though I want to clarify how this might behave to be useful. Let's be clear. You might want the *element* functions to default to the default namespace of the document (actually a better rule would be to default to the namespace of the element on which the function is called), but you certainly wouldn't want the *attribute* functions to. Attributes aren't in a namespace. When creating attributers the correcty way you pass |null| as the namespace in ECMAScript: createAttributeNS(null, 'x'); If you pass 'http://www.w3.org/2000/svg' instead of |null| you'll end up with the same problem you have with elements, but now it's the *attributes* that you create that won't be recognised. The only common exception to this rule in SVG is the 'xlink:href' attribute. In it's case, because the attribute has a namespace prefix (xlink), you pass the XLink namespace URI instead of null. createAttributeNS('http://www.w3.org/1999/xlink', 'x'); With that out of the way, on to your question. Why shouldn't createElement('x'), say, default to createElementNS(' http://www.w3.org/2000/svg', 'x') in SVG documents? Well first of all, we should look at what the relevant specifications say we should do. If a specification is clear on something, then that's what an implementation should do. If implementations don't, we end up with a mess, where everyone does things differently. So what do the specifications say? Well first off, there are clear instructions to content authors. The namespace ignorant methods (createAttribute et. al.) should not be used in namespaced XML, and the namespace aware methods (createAttributeNS et. al.) should not be used in namespaceless HTML. http://www.w3.org/TR/DOM-Level-2-Core/core.html#Namespaces-Considerations So authors have clear instructions. In HTML use the simpler namespace ignorant methods. In XML (yes, that includes XHTML, SVG, etc.) use the longer namespace aware methods. 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.) 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. 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. 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. Otherwise people developing for SVG will get confused when the try to write a bit of XHTML or MathML. Unfortunately if they change it for other types of XML, people writing those languages are going to get confused too. Specifically, why does my script written for version Y not work in version X of the same browser, let alone in different browsers? I'm not saying that it can't or that it shouldn't be changed. I just want to point out that this isn't the simple, magic bullet change it might first appear to be. The bottom line is that namespaces are a pain. This has been compounded in the SVG world by the confusion added by the decision of past ASV teams to be "helpful" when it comes to namespaces. Unfortunately when peoples first real experience of scripting for XML is scripting for ASV, they're in for a nasty shock when they meet the real, big, bad XML world. ASV was where I cut my XML teeth, and I know it was for me. 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. I believe they are the current gardians of the core DOM specifications. Perhaps they could add that change to DOM3. Without this being specified in a specification I don't hold out much hope of your proposal being widely and consistantly adopted. There just isn't enough of a weight of SVG on the web to convince the wider XML world that there will be less pain all round in making this change. Anyway, sorry for being so longwinded. I hope at least some of this has been a useful contribution to the current thread. Regards, Jonathan [Non-text portions of this message have been removed] ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/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/
