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


From: Ray Whitmer <ray@personallegal.net>
Date: Sun, 4 Dec 2005 07:22:17 -0700
Message-Id: <E96DC878-6AA5-4BDC-8A13-9D9D120EC536@personallegal.net>
Cc: DOM mailing list <www-dom@w3.org>, Maciej Stachowiak <mjs@apple.com>
To: Thomas Much <thomas@snailshell.de>

On Dec 2, 2005, at 6:36 AM, Thomas Much wrote:

> am 01.12.2005 2:10 Uhr schrieb Maciej Stachowiak unter mjs@apple.com:
>> The DOM Level 3 Core (and Level 1 and Level 2) spec requires
>> WRONG_DOCUMENT_ERR to be raised in many cases where a child is
>> inserted into a document other than its owner document, for example,
>> here for appendChild:
> [...]
>> I'd like to request an erratum to make raising this exception
>> optional.
> Yes, please. Like Safari, we've had exactly the same problem  
> (following the
> specs too closely) in iCab, and we're now about to violate the  
> specs and not
> throw WRONG_DOCUMENT_ERR, because our customers do not care about  
> standards
> - they just want to see web pages that other browsers can display.
> By making this exception optional (not required), there should not  
> be any
> need to rewrite existing non-browser DOM implementations IMHO. Or  
> maybe the
> erratum can be restricted to browser implementations due to "legacy  
> issues".

I suggest you:

1. Talk to your W3C AC Representative about this issue.  If you do  
not have one, find a friend who has an active W3C AC Representative  
and might care.  I say that because I have seen no one from W3C take  
note of this public mailing list for a while, and my own attempts to  
send email to the W3C internal mailing lists or personnel who  
formerly dealt with DOM have failed but I have no company right now  
that I would represent at W3C with stronger contacts.  Companies can  
join (and appoint an AC Rep) for a fee that is affordable and smaller  
for smaller companies for anyone with an interest in their current  
activities or who believes their direction can be adjusted.  Having  
an existing AC Rep that is up to speed cannot be taken for granted,  
otherwise how did this gap occur?

2. Explain that the specification seems to possibly allow it to be  
optional (if supported) but the test suite flags it as a failure.  It  
certainly seems to me like it might from the description of the error  
message and that is combined with the fact that many have implemented  
it that way (supporting the interpretation).  I have not done deeper  
research, and will not without a bigger reason and W3C paying  
attention.  It would seem like it might be possible to make it an  
errata along this line of reasoning, assuming there is even someone  
doing maintenance (which is why you have to talk to AC Rep).   
Otherwise, you are reversing three levels of the spec and six years  
of adoption of an accepted recommendation.

The getAttribute issue is a harder one, because we are dealing with a  
very intentional return value specified by the specification that at  
least initially was probably correctly implemented by browser  
designers/adopters of DOM Level 1 (who pushed for it).  Of course,  
there are ways to cause your app to switch behavior either manually  
or automatically -- not pretty but possible.

But I could be wrong.

Ray Whitmer
Received on Sunday, 4 December 2005 14:22:35 UTC

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