501226 - When XMLSerializer serializes an HTML element, it adds generates extra xmlns attribute

Status: RESOLVED DUPLICATE of bug 500937

(Core :: DOM: Serializers, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Testcase:
Open a new tab and load 
javascript:alert((new XMLSerializer).serializeToString(document.body));

I believe this is a regression from making html elements to be in
xhtml namespace.

Comment 1

[Jesse Ruderman]

What's wrong with that?  You ask an XML serializer to serialize a DOM subtree as XML, you get working XML.

Before the fix for bug 468708, you'd get non-working XML.  How was that better?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Good point. We probably need a separate HTMLSerializer object. (Or even better, a cleaner serializer object that can do both).

Comment 3

[Jesse Ruderman]

innerHTML kinda does that, but I'll attach the HTML serializer I use when I'm reducing fuzz testcases.  It includes a bunch of warnings for DOMs that can't be serialized as HTML.

Comment 4

[Jesse Ruderman]

Attachment: Jesse's serializeHTML.js

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #1)
> What's wrong with that? 

We have never done that, and other browsers don't do it either.
https://bugzilla.mozilla.org/show_bug.cgi?id=469304#c8.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Testcase

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(And this is yet another case where 'HTML-elements-have-XHTML-namespace' cause
additional hacks. Other cases are for example XPath.
But I'm probably the only one who doesn't like HTML5's namespace handling.)

Comment 8

[Henri Sivonen (:hsivonen)]

The whole point of putting the HTML elements in the http://www.w3.org/1999/xhtml namespace is that you can treat HTML documents as XML documents as far as XML-oriented code goes.

Does existing content use XMLSerializer and expecting the output not to be XML when the input document is an HTML document? Thus, if existing content doesn't depend on XMLSerializer producing non-XML under certain conditions, I'd consider this a feature.

Note that the old behavior was that the output was neither HTML nor XML, which doesn't really make sense, so XMLSerializer didn't work as an "HTMLSerializer" before, either. (I got <DIV/> in the latest Firefox 3.5 RC.)

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> Does existing content use XMLSerializer and expecting the output not to be XML
> when the input document is an HTML document?

Actually, there's quite a big risk that they do. I.e. there's quite a big risk that people use XMLSerializer as a HTML-serializer.

I don't think this is a big problem in practice though. Most likely the main difference you'll see is an extra xmlns attribute showing up once you reparse as HTML.

Unless we see major site breakage over this I don't think we should worry.