Re: [dom3core] WRONG_DOCUMENT_ERR

On Dec 2, 2005, at 3:54 AM, Ray Whitmer wrote:

>> Do you actually have a browser, or is this a hypothetical?
>
> Have you heard of Firefox?  I represented AOL / Netscape last on  
> the DOM committee, and as with other issues, we spent lots of time  
> talking to group members reaching a consensus.  Johnny Stenback was  
> there doing DOM work from Netscape as were others. Now, where does  
> the 98-99% come from, without including Mozilla-based browsers?

Firefox has the implicit adoption behavior. I am surprised you don't  
know.

We added it to Safari to copy Mozilla-based browsers, in fact, based  
on complaints that certain web sites worked with Firefox but not in  
Safari. Instead of telling our users that these Firefox was broken  
and not DOM compliant, we added support for implicit adoption.


>>> 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?
>
> It is not the same, because it is an API that is clearly designed  
> to be optionally supported, with alternative methods for situations  
> where it might fail.

How does that make a difference? Either way it is possible to write  
code that is portable to multiple implementations, or code that  
depends on implementation details.

> There are also cases where the implementation is possible with an  
> explicit adoption that it is not without an explicit adoption, for  
> example to support the ownerDocument attribute for a node which is  
> currently not attached in the child hierarchy of the document in  
> question, which I remember was a concern of the group.  Does your  
> implementation properly implement the ownerDocument attribute?

Yes, Safari supports ownerDocument and updates it when nodes are  
moved between documents.

> Just because there are no current tests you fail does not at all  
> mean you have a compliant implementation.

Safari *does* fail some of the DOM test suite. That's the whole point  
of my email.

> The test only demonstrates that someone implemented certain tested  
> points of the standard.  No test can ever prove compliance to this  
> sort of standard and the test suite was never designed for tthat.   
> It only proves non-compliance.

Sure, this is why I suggested an update to the standard as well as to  
the test suite.

> What we have was the group consensus.  Now, are you going to set up  
> a working group to get the same participant companies back into the  
> room because you couldn't make the prior meetings when the issue  
> was on the table (good luck with the logistics), or is there little  
> point to your complaints at this point?

I think your tone is needlessly combative here. I wasn't even working  
on a web browser when DOM Level 1 Core was written, let alone aware  
of this issue. I don't think that makes it unfair for me to bring it  
up, now that I know about it.

>> 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.
>
> There is no standards-based solution to broken HTML or broken  
> javascript, at W3C and I believe there never will be. If you need  
> to support it, you have to figure it out yourself.
>
> The same sort of solution I mentioned previously with respect to  
> the getAttribute might be tried in this case if one were looking to  
> actually support the consensus-based W3C DOM solution.

Whose consensus is it? It doesn't appear to be a consensus of browser  
authors, since browser implementations do not match the spec on this.

> The possible approaches of browsers to broken DOM scripts does not  
> seem that far removed from the approach of browsers to broken HTML  
> which most support (and unfortunately often do nothing to guide web  
> authors to clean up their HTML or Javascript, which would be quite  
> easy).

I don't see how it's possible to apply HTML loose parsing style  
technologies to something like this. How can you possibly tell if the  
calling script expects the exception or not?

> I could name any number of other features broken in IE, so should  
> we continuously update the standard to reflect the bugs de jure,  
> hurting anyone who followed the specification?  While I would never  
> rule out what might be appropriate in some particular situation,  
> this seems inappropriate in these situations.
>
> I have authored a number of web sites myself and have lots of  
> friends who have and have never come across either of these abuses  
> of the standard, and there are any number of others you are leaving  
> out if you wish to convert the DOM standard into an inherently- 
> incomplete manual on the behavior of IE with no regard to the  
> consensus.

I think this is an unfair characterization of my suggestion. The tiny  
relaxation of the spec I proposed would simply permit the behavior  
currently implemented by Firefox, Internet Explorer and other web  
browsers, and expected by numerous web sites. I do not think all  
deviations from the spec should be codified.

Regards,
Maciej

Received on Friday, 2 December 2005 19:26:14 UTC