263144 - prefixed XHTML elements are not rendered properly

Status: VERIFIED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Manos Batsis]

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:

Comment 1

[Manos Batsis]

Attachment: testcase that demonstrates the rendering issue and all the steps that lead to the redundant prefixes

Comment 2

[Hixie (not reading bugmail)]

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...

Comment 3

[Manos Batsis]

Attachment: testcase that demonstrates the rendering issue and all the steps that lead to the redundant prefixes

Sorry, attached the wrong file :-/

Comment 4

[Manos Batsis]

Attachment: minimal testcase demonstrating the issue on non-dynamic content

Comment 5

[Manos Batsis]

BTW, if the minimal attachment(161253) is viewed as application/xhtml+xml, the
rules are not applied at all (correctly of course).

Comment 6

[Martijn Wargers (dead)]

Attachment: 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.

Comment 7

[Peter Van der Beken [:peterv]]

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.

Comment 8

[Manos Batsis]

(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

[Anne (:annevk)]

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.

Comment 10

[Manos Batsis]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Peter Van der Beken [:peterv]]

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

[Anne (:annevk)]

> What should I do, go back to HTML?

Yes.

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

->VERIFIED