W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005


From: Ray Whitmer <ray@personallegal.net>
Date: Thu, 1 Dec 2005 07:46:16 -0700
Message-Id: <50EE1EAE-3C1F-4AD5-80B4-8BDA48BE26FF@personallegal.net>
Cc: DOM mailing list <www-dom@w3.org>, vicki Murley <vicki@apple.com>, andersca@mac.com
To: Maciej Stachowiak <mjs@apple.com>

On Nov 30, 2005, at 6:10 PM, Maciej Stachowiak wrote:

> The DOM Level 3 Core (and Level 1 and Level 2) spec requires  
> WRONG_DOCUMENT_ERR to be raised in many cases where a child is  
> inserted into a document other than its owner document, for  
> example, here for appendChild:
> http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ 
> core.html#ID-184E7107
> However, historically browser-based DOM implementations have let  
> you reparent elements freely, and there are in fact web sites out  
> there that create an element in one document and then insert it  
> into another. Safari actually limits the reparenting to the case of  
> elements that have never been in a document, to cover such sites.
> This is causing Safari to fail 5 tests in the DOM Level 1 Core test  
> suite, these are our only failures besides the getAttribute issue  
> mentioned by Anne.
> I'd like to request an erratum to make raising this exception  
> optional. There does not seem to be much benefit to requiring DOM  
> implementations to enforce this limit.

Just because you know of browsers able to do this doesn't mean it is  
a good idea to allow it.

There are many legitimate reasons why browsers wouldn't always be  
able to do this, i.e.:

Placing memory for different document types into different allocation  
pools, having different types of objects support HTML documents,  
versus XML, versus SVG, etc, and so on.

When someone says "my code doesn't work in your browser, which you  
claim to be DOM-compliant", but it worked in Safari, I am much  
happier to tell them "that is because Safari is not DOM compliant"  
rather than telling them "that is because DOM isn't interoperable  
between two implementations in this feature, even though you complied  
with the standard".  That is why making exceptions optional in this  
sort of case is a bad idea, and we created alternative mechanisms to  
allow all implementations to handle the situation.

Ray Whitmer
Received on Thursday, 1 December 2005 14:46:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC