Do we need to enforce docType position through DOM modification

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
P3
normal
RESOLVED WORKSFORME
15 years ago
7 years ago

People

(Reporter: peterv, Assigned: peterv)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

15 years ago
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.)
(Assignee)

Comment 2

15 years ago
> (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.
(Assignee)

Comment 6

15 years ago
Ok, so then this bug is about preventing insertion of a documentElement before
the docType.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.6beta

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
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.