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

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.