Bug 7480 – non-HTML elems w/o children in HTML docs get serialized self-closing

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Darin Adler]

I looked at the code in markup.cpp and by code inspection noticed that the logic was wrong. My fixed version makes XML serialization work a little better.

[Darin Adler]

Created attachment 6749 [details]
patch

[Darin Adler]

By the way, when I tried the tests, Gecko used "<tag/>" rather than "<tag />".

[Maciej Stachowiak]

Proposed rules for serialization:

1) For HTML documents (HTMLDocument, parsed as HTML), always use HTML serialization rules. Elements that must be empty get no close tags, other elements get close tag even if they happen to have no children.
2) For XML documents, serialize as follows: HTML elements that must be empty in HTML are serialized with " />" syntax; other HTML elements are always serialized with a close tag; non-HTML elements follow normal XML rules.

The benefit of this is, if you serialize an XHTML document and try to treat the results as HTML, it will work, since people may want to edit as XHTML but then will almost invariably serve the result with a text/html mime type on the web.

This is what the old code was trying to do. I am not sure if it had a bug in implementing these rules. But the patch clearly makes it not follow these rules.

[Maciej Stachowiak]

(By "normal XML rules" I mean don't bother with the extra space before "/>" when using minimized syntax.)

[Darin Adler]

Now I understand what the actual bug is. I'll do a new patch.

[Darin Adler]

Created attachment 6756 [details]
patch, presumably will get review- because of lack of a layout test

[Darin Adler]

Comment on attachment 6756 [details]
patch, presumably will get review- because of lack of a layout test

Strangely, I discovered that custom elements in HTML documents are HTML elements. This doesn't make sense to me. I'll investigate further.

[Darin Adler]

Created attachment 6788 [details]
patch

[Eric Seidel (no email)]

Comment on attachment 6788 [details]
patch

Looks good.  As you mentioned before, it does seem a bit odd that unrecognized elements end up as HTMLElements in an HTML document (and thus are serliaized in all caps)

r=me

[Maciej Stachowiak]

I believe all browsers will make unrecognized elements into HTMLElements in an html document, and the specs may even require this. HTML4 mandates supporting unknown elements and rendering their contents.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.