Mozilla currently binds namespace declaration Attributes to "" or null respectively This is a DOM2/DOM3 Violation. From http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020114/core.html#Namespaces-Considerations Note: In the DOM, all namespace declaration attributes are *by definition* bound to the namespace URI: "http://www.w3.org/2000/xmlns/". These are the attributes whose namespace prefix or qualified name is "xmlns". Although, at the time of writing, this is not part of the XML Namespaces specification [Namespaces], it is planned to be incorporated in a future revision.
Would someone be able to attach a simple testcase for this?
http://www.w3.org/TR/1999/REC-xml-names-19990114/#scoping-defaulting A default namespace is considered to apply to the element where it is declared (if that element has no namespace prefix), and to all elements with no prefix within the content of that element. If the URI reference in a default namespace declaration is empty, then unprefixed elements in the scope of the declaration are not considered to be in any namespace. Note that default namespaces do not apply directly to attributes.
Confirming since there is _some_ issue here that should be acted on....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Testcase as requested: This script which demonstrates the wrong behaviour <?xml version="1.0" encoding="iso-8859-1"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" > <head> <script> elt=document.documentElement; output ='Namespace: '; output+=elt.attributes.getNamedItemNS(null,"xmlns:xul").namespaceURI+"\n"; output+='Local Name: '; output+=elt.attributes.getNamedItemNS(null,"xmlns:xul").localName+"\n"; alert(output); </script> </head> </html> produces: Namespace: null Local Name: xmlns:xul According to the above quoted DOM2/3 Spec. this is behaviour is wrong. The 'xmlns' and 'xmlns:<namespace>' Attributes must be accessible by for example getNamedItemNS("http://www.w3.org/2000/xmlns/","xmlns:xul") With this modification the above script must deliver: Namespace: http://www.w3.org/2000/xmlns/ Local Name: xmlns:xul But instead getNamedItemNS("http://www.w3.org/2000/xmlns/","xmlns:xul") is undefined which is obvious, since the node cannot be bound to two namespaces at the same time.
I did not understand the issue here, the docs also says: If the URI reference in a default namespace declaration is empty, then unprefixed elements in the scope of the declaration are not considered to be in any namespace
Sivakiran, my original posting is *not* about *default* namespaces. My posting is about *predefined* namespaces. A default namespace is defined (or left undefined) by the author of an XML-Document as they may like it by (not) using the xmlns="<URI>" syntax on an element. Furthermore you quote: "Note that default namespaces do not apply directly to attributes." Thus your qoute does not apply in two respects: a) attributes are not affected by the author-defined default namespace b) but even if they were: DOM Specs (and future XML Specs) make an explicit exception to the two "namespace declaration attributes" in that they bind these directly to the stated namespaces. Again: Your qoute is about *declaring* default namespaces on *elements* (through xml document authors) which has nothing to do with my bug report. My qoute is about the *predefined* namespace binding (through the standards body) to two very special *attributes*.
Medium severity, low visibility, no real-world application currently -> P4. Boris if this is important for you, please let us know :-)
OS: Linux → All
Priority: -- → P4
Hardware: PC → All
Fabian: this bug is currently causing me a major issue for bug 112775. I have to detect all currently enabled namespaces for a given document, for the conveinience of the user having a predefined namespaces dropdown textbox. If the XMLNS namespace were enabled, this would be possible.
i'm pretty sure i fixed this on when i implemented namespaced attributes for html-elements
Created attachment 109063 [details] Testcase, correctly written Testcase in comment 4 is flawed. Corrected testcase shows correct behavior, I think. If so, this bug is WORKSFORME.
Assignee: jst → bugmail
this was fixed along with bug 41983
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
v per testcase
Status: RESOLVED → VERIFIED
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.