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


From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 3 Dec 2005 02:25:02 -0800
Message-Id: <D5A21157-B813-49C5-BC46-710604D50D80@apple.com>
Cc: DOM mailing list <www-dom@w3.org>
To: Curt Arnold <carnold@houston.rr.com>

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.

Received on Saturday, 3 December 2005 10:25:17 UTC

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