testcase that demonstrates the rendering issue and all the steps that lead to the redundant prefixes
2.38 KB, text/html
530 bytes, text/html
465 bytes, application/xhtml+xml
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:
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...
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
Attachment #161252 - Attachment mime type: text/plain → text/html
Attachment #161253 - Attachment mime type: text/plain → text/html
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.
(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).
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.
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">'+
> 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.