Re: [DOM4] Mutation algorithm imposed order on document children

On Thu, Jun 14, 2012 at 2:49 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jun 13, 2012 at 7:47 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
> > So it seems the one element, one doctype rule is already pretty well
> > enforced.
>
> And why do we not want to enforce ordering? I'm not entirely sure what
> the goal is here.
>

To simplify implementation. Making this work at the very least adds more
branching to insertBefore/appendChild, potentially slowing them down. I'd
be OK with that if we got something out of it, but I still don't see any
benefit to enforcing ordering. Boris's suggested use-case of a script
blindly messing with the DOM isn't compelling to me. Sure, scripts might do
that, but I don't see the downside of allowing it.

This is comparable in my view to enforcing that table cells always go in
table rows. HTML parsing enforces that, but appendChild/insertBefore/etc
don't. I think the same should apply to this issue.


> > I'd like to change the spec so that instead of requiring a specific
> > ordering, it requires that the serialization of the document (for example
> > through XMLSerializer) always reflects the current document state, even
> if
> > you removed the doctype node entirely. That ensures that serializing a
> live
> > document gets you something that would render the same a second time.
>
> So HTML documents would always get the same doctype in standards mode,
> the same doctype in almost standards mode, and the same doctype (or
> maybe lack of) in quirks mode? Would that only happen if the doctype
> was meddled with? What about XML documents? What is the processing
> model going to be?
>

This sounds too complicated to me as well. Making the serialized output
always have the same compatMode sounds great if we could make it work, but
I can't think of any solution that isn't too complicated to be worth it.

Again, as far as I'm aware, this is a problem people just don't hit in
practice. If they mess with the DocType, it's so that they can get a
certain compatMode and thus they use document.write.

Lets just do the simplest thing. It's not the end of the world if we have
to implement this in WebKit obviously, it just seems unfortunate when
there's no good use-case.

IMO, we should even take it a step further and not have any restrictions on
how many doctype/element nodes a document can hold. We just spec it that
the UA ignores any doctype/element nodes in the document after it
encounters the first node of each type.