Closed Bug 464594 Opened 16 years ago Closed 16 years ago

XHTML attributes with qualified names not recognized

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: matt-mozilla, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.22
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

If an XHTML file defines a namespace prefix which refers to the XHTML namespace and then uses that prefix to specify XHTML attributes using qualified names, those attributes are not recognized correctly.

An example of the bug may be seen at: http://goliath.cs.ucdavis.edu/bugs/qname_attr_test.xhtml

The file is an XHTML 1.1 document, served with Content-Type: application/xhtml+xml.  It defines xmlns:h="http://www.w3.org/1999/xhtml" and uses the "h" prefix to construct the qualified attribute names "h:id" and "h:href".  Neither attribute is correctly handled by Firefox: the CSS style that should apply to div#yes elements isn't applied nor is the link href interpreted correctly.

This problem also occurs with Firefox 3.0.3 Linux and Minefield 3.1b2pre on OS X (i.e. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081112 Minefield/3.1b2pre).



Reproducible: Always

Steps to Reproduce:
1. Load http://goliath.cs.ucdavis.edu/bugs/qname_attr_test.xhtml
2. Note that CSS style which would indicate id attribute being recognized correctly isn't applied, nor is the href attribute on the link.
Actual Results:  
The :after content of the div with id="yes" is set to "No".  The link does not point to "#".

Expected Results:  
The :after content of the div with id="yes" should be set to "Yes".  The link should point to "#".
Attributes are in the "null" namespace, not the xhtml namespace. I'm pretty sure this bug is invalid.
Unprefixed attributes are in the "null" namespace by default.  However, I haven't been able to find anything in any of the XHTML specifications that states that they MUST be in the "null" namespace.  Indeed, Opera 9.5 interprets that test page as I would expect, recognizing that the attributes in the XHTML namespace should be interpreted as XHTML attributes.

Additionally, Section A.2.2 of the XHTML Modularization 1.1 Recommendation leads me to believe that optionally prefixing attributes is valid.  It reads, "... while local attributes depending on the schema implementation may be explicitly prefixed." (See: http://www.w3.org/TR/xhtml-modularization/schema_module_rules.html#s_module_namespace )

If I am missing some stricture of the XHTML Recommendations that you could point me to, I'm keen to be corrected.
I believe you have to infer it from http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict and http://www.w3.org/TR/2006/REC-xml-names-20060816/#defaulting

http://www.w3.org/TR/xhtml-modularization/schema_module_rules.html#s_module_namespace means that the xhtml document can have a namespaced attribute without it being a parse error providing the namespace is defined. It does not mean that it such an attribute is treated as an alias of an attribute of the same name in the null namespace.
See bug 442534 comment 2
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.