Re: [dom3core] WRONG_DOCUMENT_ERR

On Dec 1, 2005, at 11:46 PM, Maciej Stachowiak wrote:

>> 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.

Please, show me the numbers' source.  Or are you just making up  
"hypothetical" numbers?

>> 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?

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?

There are/were at the time several DOM implementations used for  
different purposes within the Mozilla product, for example, between  
HTML documents, XML data being sent via http requests, SOAP requests,  
etc. and possibly other fundamental types of documents that were not  
compatible to be inserted inside each other.

I would suspect although I cannot claim for certain from memory that  
IE may have similar problems between different DOM implementations in  
the product.  There was much emphasis at the time on being able to  
support diverse DOM implementations, both for browsers and for Java.

>> 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.

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?

Just because there are no current tests you fail does not at all mean  
you have a compliant implementation.  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.

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?

> 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.  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 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.

Ray Whitmer
ray@personallegal.net

Received on Friday, 2 December 2005 11:55:40 UTC