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