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

Re: [dom3core] WRONG_DOCUMENT_ERR

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 3 Dec 2005 00:51:12 -0800
Message-Id: <DDFA91BD-3ECF-492A-B3BF-E4A42CD483B5@apple.com>
Cc: DOM mailing list <www-dom@w3.org>, vicki Murley <vicki@apple.com>, andersca@mac.com
To: Ray Whitmer <ray@personallegal.net>


Hi Ray,

On Dec 2, 2005, at 6:05 PM, Ray Whitmer wrote:

> On Dec 2, 2005, at 12:26 PM, Maciej Stachowiak wrote:
>
>> Firefox has the implicit adoption behavior. I am surprised you  
>> don't know.
>
> Expect me to continue to respond to your ongoing jabs with my own  
> questioning of your own knowledge, if I continue to respond at all.

My apologies. I didn't mean this to come out as rude as I am sure it  
sounded. I was also frustrated by the uniformly negative tone of  
replies to my messages. I proposed errata to the spec originally  
because Curt Arnold suggested this approach to compliance vs.  
compatibility conflicts in the test suite(*). But now even he seems  
critical of this approach.

Anyway, I would like to get past the negativity and try to discuss  
this issue constructively. I do think it is a real and serious  
problem, and I would like to find a way to fix it.

So here are some facts and information that you may find useful  
(hopefully new):

> I am relatively certain Firefox does not have implicit adoption in  
> some cases and therefore benefits from exceptions being thrown, as  
> I have explained several times now.

Safari also declines to do implicit adoption in some cases. But  
throwing the exception sometimes appears just as noncompliant with  
the spec as throwing it never.

> I am happy you have discovered the standards, and I will be happy  
> when Safari is more compliant through your efforts. It is unfair  
> for you to attack on the issue and ignore the answers or the  
> explained historical justifications of the standard and the current  
> state of the standard's process.

I do not think that there is anything wrong with the standard being  
the way it is (and thanks for the historical notes), what I am hoping  
for is consideration for making changes.

> Admittedly DOM Levels 1 and 2 lacked a test suite when it was  
> released, but a test suite cannot test all parts of the  
> specification or all important parts for all cases to bring out the  
> issues, either, which an implementer should adhere to.

This is where a "multiple interoperating implementation" requirement  
would have helped, as pointed out by L. David Baron.

> Are you being sarcastic/combative again, or seriously thinking I  
> was suggesting applying HTML parsing technology to javascript?

No, I actually don't understand your suggestion. Here's what current  
web browsers do to handle nonconformant web content (sorry if this  
isn't news to anyone, but perhaps it is of interest to anyone focused  
more on Java-based implementations):

1) Loose parsing - when parsing an HTML document, browsers accept  
many constructs that are technically illegal, such as tag nesting  
that violates the DTD, syntactically invalid attribute values, and so  
forth. Most of this loose parsing is always on and is not controlled  
by any kind of switch. Indeed, sending XHTML 1.0 with a "text/html"  
MIME type depends on this.

2) Quirks rendering - this provides legacy rendering for certain HTML  
and CSS constructs, with fully standards-compliant rendering  
requested by providing a proper HTML4 doctype declaration. (And some  
parsing quirks are also based on the doctype switch.) Note however  
that so-called strict mode still leaves many nonstandard extensions  
in place. It just turns off quirks that actively conflict with the  
standard rendering. Also, quirks mode applies only to rendering and  
layout, not to behavior for a number of reasons (including  
feasibility of testing that switching to a strict doctype didn't  
break your site).

3) Provision of nonstandard DOM methods and properties for  
compatibility - all browser-based implementations extend DOM  
interfaces with nonstandard methods and properties, for compatibility  
with other browsers.

I don't think any of these three approaches can be applied in any  
obvious way to the problem at hand.

> However, if you had read other emails I wrote on the topic this  
> morning, you would discover that I am questioning whether the test  
> is correct at all because of the language found in the specification.

Sure, I did notice that, and I appreciate it. It would be a  
convenient resolution if the spec can be read as calling for the de  
facto behavior here.

>> 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.
>
> The way I understand it, the standard will not change without  
> significant working group activity, and it would have to be a new  
> standard if incompatible with DOM Levels 1, 2, & 3, i.e. if  
> behavior prescribed by the original standard is not prescribed by  
> the new standard.

I did acknowledge it, and asked if there was any interest in  
chartering a working group to come up with some minimal set of  
changes for a browser-compatible DOM spec. However, the private email  
responses I received on this were uniformly against the idea.

I'm going to bow out of this discussion for now barring any  
surprising further developments. It doesn't seem like there is  
currently much interest in pursuing this, either through errata or  
through formation of a new working group. But if there were to be,  
I'd be glad to help.

Regards,
Maciej

* - See e.g. http://bugzilla.opendarwin.org/show_bug.cgi?id=4569
Received on Saturday, 3 December 2005 08:51:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT