prefixed XHTML elements are not rendered properly

VERIFIED INVALID

Status

()

Core
DOM
VERIFIED INVALID
14 years ago
5 years ago

People

(Reporter: Manos Batsis, Unassigned)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910

Short version: XHTML Elements that are serialized and appended to document via
innerHTML bear redundant namespace prefixes. This breaks rendering as CSS rules
are not applied to these elements.

This only applies to the case of XMLSerializer > innerHTML (see attached 
testcase). The thing is, since both the serializer and the innerHTML method
*know* this serialization goes to the host document (which is XHTML and already
has the namespace as default and the node that is serialized is actually the
result of document.importNode) maybe the prefix should be supressed at some
point, unless this can be fixed via CSS. The thing is that the CSS situation is
already complicated, as the rules in my page should not be applied to *any*
paragraph (i havent used any @namespace).

Reproducible: Always
Steps to Reproduce:
(Reporter)

Comment 1

14 years ago
Created attachment 161251 [details]
testcase that demonstrates the rendering issue and all the steps that lead to the redundant prefixes
The prefixes shouldn't make the slightest difference to CSS.

Could you create a real testcase (1k or less, no external resources) that 
clearly demonstrates the problem?

Thanks...
(Reporter)

Comment 3

14 years ago
Created attachment 161252 [details]
testcase that demonstrates the rendering issue and all the steps that lead to the redundant prefixes

Sorry, attached the wrong file :-/
Attachment #161251 - Attachment is obsolete: true
(Reporter)

Comment 4

14 years ago
Created attachment 161253 [details]
minimal testcase demonstrating the issue on non-dynamic content
(Reporter)

Updated

14 years ago
Attachment #161252 - Attachment mime type: text/plain → text/html
(Reporter)

Updated

14 years ago
Attachment #161253 - Attachment mime type: text/plain → text/html
(Reporter)

Comment 5

14 years ago
BTW, if the minimal attachment(161253) is viewed as application/xhtml+xml, the
rules are not applied at all (correctly of course).
Created attachment 161257 [details]
minimal testcase demonstrating the... (application/xhtml+xml mode)

Same testcase as minimal testcase, but in application/xhtml+xml mode.
I removed the comments surrounding the css, and made it correct xml.
You'll see that both <p> elements get a green background color now.

In text/html the second <p> element doesn't get the green background-color,
because html documents don't know anything about namespaces, I think.
In attachment 161253 [details] you're inserting elements in the XHTML namespace into an
HTML document. Why not just create HTML elements? Drop the XHTML namespace and
things work as you want them to.
(Reporter)

Comment 8

14 years ago
(In reply to comment #7)
> In attachment 161253 [details] you're inserting elements in the XHTML namespace into an
> HTML document.

Um, it's an XHTML document with a doctype and all. The only thing making it
invalid XHTML is the undefined xhtml:p element (ok and the <br /> should not be
there).


Comment 9

14 years ago
It's not XHTML. The MIME type makes it XHTML, not your DOCTYPE. I'm not sure
what Ian meant in comment 2, but I guess this is INVALID.
(Reporter)

Comment 10

14 years ago
Thanks but the DOCTYPE was authored by w3c ;-)

Seriously now, throwing the MIME answer to this is both irrelevant and impractical. 

Irrelevant: I don't actually ask prefixed elements to be styled when serving as
text/html (the prefixes make the markup invalid anyway), I'm looking for a way
to get away without the redundant prefixes in the document. Setting the
innerHTML of a node is usefull even against appendChild as a more performant
solution, so why not make it clever enough to remove the prefixes/declarations?
I also suggest having importNode as a precondition for this, as I thought it may
be of help. 

Impractical: with the persentage of the web able to handle
application/xhtml+xml, i don't have a choice. What should I do, go back to HTML?

Thanks for listening.
Actually, Anne and Peter are right.  Using the text/html with XHTML is allowed
only if the XHTML satisfies the backwards-compatibility requirements spelled out
in Appendix C of the XHTML specification.  Such documents are NOT parsed with
XML parsers but with the tag-soup parser.  So in fact, namespaces do not belong
in such documents.

Marking invalid, since you are in fact inserting XML in a non-XML document, as
Peter said.

I appreciate your inability to use the proper XHTML MIME type due to IE bugs,
but that doesn't mean we need to completely break our XML support to deal with it...

For further reading, I recommend http://www.hixie.ch/advocacy/xhtml -- that
explains the issues involved at length.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
To clarify, the discussion in bug 155723 is about using innerHTML on actual
XHTML documents, sent with a proper XML MIME type.  Those should all handle
namespace prefixes correctly.

One more thing I just noticed.  Comment 0 says:

> The thing is, since both the serializer and the innerHTML method
> *know* this serialization goes to the host document

The serializer does NOT in fact know that.  It has to serialize as something
that, when saved to an XML file and then viewed would get rendered as XHTML. 
Which means it needs to put a namespace on things.

The bug I was thinking you were talking about is that the XHTML with these
namespace prefixes, when loaded as XHTML, does not work.  That's clearly not the
case (as the XHTML testcase in this bug demonstrates).

The remaining issue (use of a prefix instead of a default namespace) is already
covered by bug 155723.
Note that my solution in comment 7 does work. Just change the line

'<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml">'+

to

'<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">'+

Comment 14

14 years ago
> What should I do, go back to HTML?

Yes.

 <http://hixie.ch/advocacy/xhtml>
 <http://annevankesteren.nl/archives/2004/07/mime>

->VERIFIED
Status: RESOLVED → VERIFIED
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.