Summary: | non-HTML elems w/o children in HTML docs get serialized self-closing | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Darin Adler <darin> | ||||||||
Component: | DOM | Assignee: | Darin Adler <darin> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Trivial | CC: | cdumez | ||||||||
Priority: | P3 | ||||||||||
Version: | 420+ | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
Attachments: |
|
Description
Darin Adler
2006-02-26 09:12:30 PST
Created attachment 6749 [details]
patch
By the way, when I tried the tests, Gecko used "<tag/>" rather than "<tag />". 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. (By "normal XML rules" I mean don't bother with the extra space before "/>" when using minimized syntax.) Now I understand what the actual bug is. I'll do a new patch. Created attachment 6756 [details]
patch, presumably will get review- because of lack of a layout test
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.
Created attachment 6788 [details]
patch
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
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. Mass moving XML DOM bugs to the "DOM" Component. |