48445 - XHTML served as text/xml is not in XHTML namespace

Status: VERIFIED INVALID

(Core :: DOM: HTML Parser, defect, P3)

Description

[Hixie (not reading bugmail)]

XHTML documents parsed as XML do not get their elements placed in the XHTML 
namespace by default for some reason, and thus are not styled.

STEPS TO REPRODUCE:
   See attached testcase. It is a valid XHTML document served as text/xml.

ACTUAL RESULTS:
   One long line of unstyled text.

EXPECTED RESULTS:
   A page that looks like a plain HTML document.

REPRODUCED ON:
   Windows 2000 commercial build 6.0.18.2000080908.

(See also bug 26021.)

Comment 1

[Hixie (not reading bugmail)]

Attachment: Test case, delivered as text/xml

Comment 2

[Hixie (not reading bugmail)]

Nominating for nsbeta3. This bug makes it impossible for web authors to migrate
to pure XHTML documents while Gecko is in use.

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

What are the requirements on non-validating XML parsers for handling FIXED
attributes?

Comment 4

[harishd]

This is probably nisheeth's area. CCing heikki and myself.

Comment 5

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-07)]

Works in IE 5 for Mac: 4xp

Comment 6

[Nisheeth Ranjan]

When you serve this XHTML document as text/xml, you need to use XML namespaces 
to attach the HTML namespace to the HTML elements on the page.  Just using the 
DOCTYPE isn't enough.  Marking this bug invalid.

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Look at the contents of the DTD mentioned by that doctype, and you'll find a
namespace declaration.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Right, there is this snippet in the DTD which defaults the namespace:

<!-- the namespace URI designates the document profile -->

<!ELEMENT html (head, body)>
<!ATTLIST html
  %i18n;
  xmlns       %URI;          #FIXED 'http://www.w3.org/1999/xhtml'
  >

Unfortunately I do not think our parser is yet up to handle this. I could almost 
bet this is a duplicate of some other bug. Reopening, someone else can find the 
dup (or mark this Future if not dup?).

Comment 9

[Nisheeth Ranjan]

3.3.2 of the XML spec lists fixed attribute defaults as a validity constraint.  
It is my current belief that expat does not report fixed attributes.  I'll find 
out for sure this week as I work on integrating the latest expat release into 
Mozilla.

The workaround for XHTML authors is to explicitly add the XHTML 
namespace attribute on the root element.  Given that we have a workaround, 
marking this a beta3- and futuring.

If it turns out that the new expat release reports fixed attributes, I'll 
rethink this decision.

Comment 10

[Hixie (not reading bugmail)]

Taking QA per managerial policy.

Comment 11

[Robin Lionheart]

Removing 4xp based on IE5/Mac, in accord with "4xp for 'competitor products'
Considered Harmful" thread on n.p.m.qa.general.

Comment 12

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-07)]

Is this bug still considered valid?

Strictly conforming documents must designate the XHTML namespace. So the
question is: What's a document that isn't strictly conforming but is nontheless
conforming enough so that Mozilla should support it? The XHMTL 1.1 spec says:
"This version of XHTML provides a definition of strictly conforming XHTML
documents, which are restricted to elements and attributes from the XHTML
namespace."
(http://www.w3.org/TR/2001/REC-xhtml11-20010531/conformance.html#doccont)

That seems to imply, that non-strictly conforming documents are different from
strictly conforming documents only in the sense that they can contain elements
and attributes from other namespaces (and not in the sense that they need not
designate the namespace explicitly).

Is there any wording in any know W3C spec saying that user agents with
non-validating parsers should infer the xmlns attribute if it isn't explicitly
included in the document? (If Mozilla didn't require the xmlns attribute to be
present, a compatibility problem would be imposed on other browsers that wish to
read XHTML, because some authors would omit the attribute.)

Comment 13

[Hixie (not reading bugmail)]

> Strictly conforming documents must designate the XHTML namespace.

Above and beyond the attribute which is given in the DTD?

I have to admit to being just out of my depth here...

Comment 14

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-07)]

>Above and beyond the attribute which is given in the DTD?

Since both the XHTML 1.0 and 1.1 specs explicitly list both the namespace
designation and the doctype declaration pointing at the DTD as requirements for
strictly conforming documents, I think it means that they want the namespace
designation to be explicit in the document. (If they didn't want it that way,
why whould they include a list item that would be redundant, if the namespace
was supposed to come implicitly from the DTD anyway?)

Strictly from the XML spec point of view, the question is: Does a non-validating
XML processor need to know about default attribute values that are declared in
an external DTD file?

I'm not sure, but I think it doesn't need to know. According to
http://www.w3.org/TR/2000/REC-xml-20001006#proc-types a non-validating XML
processor is required to only process the "internal DTD subset", which, I think,
means that declarations in an external DTD file don't matter.

Comment 15

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-07)]

Attachment: The test case with an internal ATTLIST

Comment 16

[Hixie (not reading bugmail)]

Agreed. I'm going to mark this bug INVALID. Thanks for explaining all that to
me, I understand the issues much better now!

Comment 17

[Henri Sivonen (:hsivonen) (away from Bugzilla until 2026-09-07)]

Marking verified.

Comment 18

[Hixie (not reading bugmail)]

*** Bug 221624 has been marked as a duplicate of this bug. ***

Comment 20

[Saul Tannenbaum]

Typoed the bug # in dupe marking.