In bug 56764 I added a check in document.insertBefore and document.replaceChild to ensure that the document's docType is before the root element. The XML spec enforces this, the XML Infomation Set spec doesn't and neither does the DOM spec. So either we fix our code to look for docTypes after the root element or we keep the current code (and fix it to enforce a new root element to be after the docType). Opinions?
IMHO we should not enforce doctype-before-root, there are several things that the DOM allows that the XML spec does not. For example '--' inside comments or ']]>' inside CDATA sections. (If we decide to not enforce doctype-before-root then we should back out attachment 133757 [details] [diff] [review] from bug 56764.)
> (If we decide to not enforce doctype-before-root then we should back out > attachment 133757 [details] [diff] [review] from bug 56764.) Not only that, we'll need to fix other code like GetDoctype to look after the documentElement too.
That would seem to be necessary based on a reading of the spec, IMHO, yes: # This provides direct access to the DocumentType node, child node of this # Document.
I disagree with this, even if the spec doesn't explicitly state that this should be enforced, there's absolutely not reason to allow this, and I can assure you that it was not the DOM WG's intent to allow a doctype anywhere other than before the root element. Show me a case where it matters, and I might care, if not, I really don't like loosening this up. And besides, document.normalizeDocument() will flag such a situation as a non-well-formed document, and such a document won't be serializable, so why let developers crawl into that corner? If anything, we should argue to the DOM spec should be clarified about this issue, and sometimes when I'm not on drugs (got out of wisdom teeth removal surgery earlier today), I'd be willing to push the DOM WG to look into this.
And yeah, sure, there's ways in the DOM where non-well-formed trees can be created, but most of those are due to the fact that the DOM WG didn't want to force implementations to inspect the value of comments and CDATA sections during creation/modification, but doing the right thing with the doctype is trivial. And besides, non-well-formed CDATA sections can be fixed on serialization/normalization, to some degree. Comments can not, though.
Ok, so then this bug is about preventing insertion of a documentElement before the docType.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.6beta
IsAllowedAsChild seems to handle this correctly.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Target Milestone: mozilla1.6beta → ---
You need to log in before you can comment on or make changes to this bug.