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


From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 1 Dec 2005 22:46:13 -0800
Message-Id: <BED818E1-189D-44F1-AE68-E7BFEECE4DAF@apple.com>
Cc: DOM mailing list <www-dom@w3.org>, vicki Murley <vicki@apple.com>, andersca@mac.com
To: Ray Whitmer <ray@personallegal.net>

On Dec 1, 2005, at 6:46 AM, Ray Whitmer wrote:

> 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.

The browsers able to do it add up to 98-99% of browser market share.  
When a web site is broken, users do not typically step back to read  
the spec, they file bug reports against the offending browser.  
Standards compliance is important to us. However, browsing the actual  
existing web is also important.

> 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.

That's fine, but the spec could be written so as to allow not doing  
it. I don't see why it is a problem to allow alternatives. There are  
other places in the spec that consider multiple alternatives to be  
conforming (for instance see below).

> 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".

Do you actually have a browser, or is this a hypothetical?

> 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.

If the alternative you're talking about is DOM Level 3 Core  
adoptNode, note that as specified it appears to be optional. The spec  
says "If supported" and says what applications should do when not  
supported. Therefore, it appears to have all the same problems that  
loosening the exception requirements on appendChild would, and the  
very same workaround to make apps that can work with both kinds of  
implementations (use importNode instead when it fails). Why is this  
behavior acceptable for adoptNode but not appendChild and the like?

But more importanly, the alternative mechanism doesn't do anything to  
help implementations browse the existing web, and therefore is not an  
actual solution to the problem I posed.

Received on Friday, 2 December 2005 06:46:28 UTC

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