- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 1 Dec 2005 22:46:13 -0800
- To: Ray Whitmer <ray@personallegal.net>
- Cc: DOM mailing list <www-dom@w3.org>, vicki Murley <vicki@apple.com>, andersca@mac.com
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. Regards, Maciej
Received on Friday, 2 December 2005 06:46:28 UTC