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 10:28:00 -0700
Message-ID: <CANMdWTv+bpL2E=zjLUiSzoAfWP9PntUW4FdfkNFjEKOcsD63eA@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 9:51 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/14/12 12:36 PM, Ojan Vafai wrote:
>
>> 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.
>>
>
> And the result is all sorts of complications in the layout code that has
> to deal with the situation.


Would allowing extra DocTypes or a DocType after the element complicate
Gecko's implementation? It's hard for me to see how since it's a node that
doesn't actually do anything.

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.
>>
>
> This would significantly increase complexity in all sorts of things that
> touch the DOM, including layout.  I'm very much apposed to doing that.


I don't think it would for WebKit, but I can see that argument and don't
feel strongly enough about this to push it.
Received on Thursday, 14 June 2012 17:28:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:09 GMT