setAttributeNS method doesn’t handle explicit XHTML namespace correctly.

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: Patrick Dark, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

XHTMLElement.setAttributeNS("http://www.w3.org/1999/xhtml", XHTMLAttributeName, XHTMLAttributeValue) doesn’t work. Based on use of |innerHTML|, it seems that the attribute gets bound to the namespace prefix |a0|. (|innerHTML| doesn’t reveal what namespace the prefix |a0| is bound to.)

Reproducible: Always

Steps to Reproduce:
1. Use XHTMLElement.setAttributeNS("http://www.w3.org/1999/xhtml", XHTMLAttributeName, XHTMLAttributeValue) on an XHTML element node in a document where XHTMLAttributeName refers to an XHTML attribute associated with that element and XHTMLAttributeValue refers to a value associated with that attribute.
Actual Results:  
Whatever effect that the XHTML attribute should have on the element is not present.

Expected Results:  
The attribute should affect the element normally. (For example, the XHTML |style| attribute’s value should cause the element’s appearance to change based on the CSS declarations specified in that value.)
(Reporter)

Comment 1

10 years ago
Created attachment 327302 [details]
This attachment tests setAttributeNS with the namespace URIs null, "", and "http://www.w3.org/1999/xhtml".

Opera 9.50 behaves as expected with all three examples. Safari 3.1.2 (525.21) behaves as expected with the first example; it does not with the latter two examples.
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general

Comment 2

10 years ago
Setting the namespace for the attribute changes its semantics, so if
style attribute is in XHTML namespace, it isn't anymore the usual
style attribute. FF3 shows the first 2 tests as 'lime' and 3rd is 'red'.

The 3rd one should be 'red' since the style attribute with namespace isn't the
one which is used for styling.

Safari handles 2nd test correctly per DOM Level 3 Core, using "" isn't the same
as null.

What we should fix is to make 2nd testcase work like Safari.

Comment 3

10 years ago
One could actually argue that DOM 3 Core is too strict, and "" could be handled
like null, since using XML the only explicit way to defined no-namespace is
to use empty value for xmlns attribute.
DOM 2 Core isn't as strict as DOM 3 Core.
(Reporter)

Comment 4

10 years ago
(In reply to comment #0)
> (|innerHTML| doesn’t
> reveal what namespace the prefix |a0| is bound to.)

It appears that I wasn’t looking closely enough at the |innerHTML| output; the prefix is assigned on the same element to the XHTML namespace. Oddly enough though, |d.getElementById("e3").getAttributeNodeNS(XHTML_NS, "style").prefix| returns |null| even though a prefix has been auto‐assigned. (I don’t know if this is a bug or not though since |innerHTML| prefixes may only be imaginary.)

(In reply to comment #2)
> Setting the namespace for the attribute changes its semantics, so if
> style attribute is in XHTML namespace, it isn't anymore the usual
> style attribute. FF3 shows the first 2 tests as 'lime' and 3rd is 'red'.
> 
> The 3rd one should be 'red' since the style attribute with namespace isn't the
> one which is used for styling.

Unfortunately, I can’t find this behavior spec’d anywhere. I don’t see anything that clearly says that what Opera is doing is wrong.

The closest things that I can find to a confirmation of what you say is Section 6.3 (in the second of two code examples) in the Namespaces in XML 1.1 spec. [1], but that doesn’t say that the attributes should not behave identically.

Of course, I do see problems that would arise if |xhtml:style| and |style| did the same thing; when both are specified, which applies? It sounds almost like the |xml:id| versus |id| issue.

(In reply to comment #3)
> One could actually argue that DOM 3 Core is too strict, and "" could be handled
> like null, since using XML the only explicit way to defined no-namespace is
> to use empty value for xmlns attribute.
> DOM 2 Core isn't as strict as DOM 3 Core.

DOM3 Core says in Section 1.3.3. [2]: “In programming languages [like ECMAScript] where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to |null|.”

Firefox 3 already seems to do this: |XHTMLElement.setAttributeNS("", "style", "background-color: lime;");| followed by |XHTMLElement.getAttributeNS(null, "style");| returns the expected result (i.e., |"background-color: lime;"|).

So, it seems to me that Safari is the one with the bug.

[1] http://www.w3.org/TR/2004/REC-xml-names11-20040204/#nsc-NSDeclared
[2] http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations

Comment 5

10 years ago
(In reply to comment #4)
> It sounds almost like the |xml:id| versus |id| issue.
No, because xml:id is specified in xml:id spec.

> DOM3 Core says in Section 1.3.3. [2]: “In programming languages [like
> ECMAScript] where empty strings can be differentiated from null, empty strings,
> when given as a namespace URI, are converted to |null|.”
Ah, indeed. So what Gecko does is right, and webkit and Opera wrong.

> though, |d.getElementById("e3").getAttributeNodeNS(XHTML_NS, "style").prefix|
> returns |null| even though a prefix has been auto‐assigned. (I don’t know
> if this is a bug or not though since |innerHTML| prefixes may only be
> imaginary.)
If this is a bug, file a new bug, thanks
 
> Unfortunately, I can’t find this behavior spec’d anywhere. I don’t see
> anything that clearly says that what Opera is doing is wrong.
http://www.w3.org/TR/xhtml-modularization/schema_module_defs.html#a_smodule_Style_Attribute
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.