W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2012

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

From: Ojan Vafai <ojan@chromium.org>
Date: Thu, 14 Jun 2012 20:43:57 -0700
Message-ID: <CANMdWTuQRPnyPkMtKvOGVH3=pQUzH_rTVm1g8Nc_SuzOULUgXw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Anne van Kesteren <annevk@annevk.nl>, Elliott Sprehn <esprehn@gmail.com>, Ryosuke Niwa <rniwa@webkit.org>, www-dom <www-dom@w3.org>
On Thu, Jun 14, 2012 at 10:52 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/14/12 1:34 PM, Ojan Vafai wrote:
>> In my ideal world, I think we'd just disallow appending DocTypes
>> entirely, but I'm sure we can't for back-compat reasons. Next best IMO
>> is allowing as many DocTypes as you want wherever you want. I'm also OK
>> with only allowing 1 DocType node before/after the element.
> What I'm trying to understand is... if you're OK for having the "only
> allow 1 doctype node" special-case, what makes it more complicated to also
> check that it's before the element?  I believe you that it does, but just
> trying to understand why.

Got it. This is the only case I know of in the DOM apis where we enforce
ordering. So, right now, WebKit just has a canAcceptChild method that takes
a pointer to the new child. It doesn't need to know where that child is
going. It doesn't need to know if you're calling appendChild or
insertBefore with a reference element. Right now, for modifying the
Document's children, it walks the Document's children and counts the number
of DocTypes/Elements already in the document and errors if there will be
more than 1 of either.

Does that answer your question?

>  Do any of the above options seem acceptable to you?
> I could possibly live with one doctype allowed to be after the element;
> the other ones seem like they violate too many invariants people might be
> depending on.

I'd be satisfied with that.
Received on Friday, 15 June 2012 03:44:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:00 UTC