- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 3 Dec 2005 02:25:02 -0800
- To: Curt Arnold <carnold@houston.rr.com>
- Cc: DOM mailing list <www-dom@w3.org>
Hi Curt, I don't want to get too embroiled, but since you asked... On Dec 3, 2005, at 1:31 AM, Curt Arnold wrote: > > If WRONG_DOCUMENT_ERR is optional, we potentially open up another > set of problems, since the spec writers (probably) and the test > writers definitely did not consider the potential scenarios that > could occur when a node is inserted in another document. Do we > know that the current implementations that don't throw an exception > implement the same behavior. Maybe one does an importNode type > action and another does an adoptNode type of action. As far as I know, both Safari and Firefox do an adoptNode type of action. I don't know of any implementation doing an importNode type action. However, reading over the Mozilla bug on this, it sounds like IE might not implement this behavior, and Safari may be affected only because dual code path web sites try to treat it like Firefox. I'll have to test this. (Mac IE seems to be up to spec, but I can't test Win IE at the moment.) > It would be reasonable to think that the original spec writers did > not want to try to think through the issues that would be required > to freely move nodes between documents and decided that the most > expedient approach to make sure that implementations were > consistent was to prohibit it. Although, the more recent adoptNode makes it explicitly optional to either work or throw WRONG_DOCUMENT_ERR. > Alternative solutions have been suggested and I don't know if > you've stated your thoughts on them. The ones that I remember off > the top of my head were: Fair enough, I'll state my thoughts now: > A Note that describes were ECMAScript implementations generally > deviate from the recommendation for compatibility with existing > content. This would be helpful, but I don't think it would be a solution to the impracticality of browsers matching the spec. There would continue to be a deviation between the spec and actual browser behavior. > A configuration option in the browser that would allow the user > (likely developer) to change between standard conformant and > compatibility mode. A visible user preference for this seems like a poor solution. It would be like having a strict mode vs. quirks mode toggle for rendering in the UI instead of triggered by something in the document. It would create a world where users would have a choice between some sites working but not others. Current generation browsers aim for a small and understandable set of preferences. If there is to be a switchable behavior here, it should be switchable by the developer of the site, not the user. But I haven't been able to come up with a workable design for this either. Does the script decide, or the document? And what triggers the decision? Another proposed solution was parsing the spec to already allow this behavior. I like this proposal but it has only been suggested for WRONG_DOCUMENT_ERR, not the empty string vs. null return issue. I think the latter is actually much more widespread. Regards, Maciej
Received on Saturday, 3 December 2005 10:25:17 UTC