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


From: Ray Whitmer <ray@personallegal.net>
Date: Fri, 2 Dec 2005 19:05:07 -0700
Message-Id: <86F78F28-6762-47A8-8BF9-BFEADCBDD05F@personallegal.net>
Cc: DOM mailing list <www-dom@w3.org>, vicki Murley <vicki@apple.com>, andersca@mac.com
To: Maciej Stachowiak <mjs@apple.com>

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.

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.  Now, should I say that I am or  
that I am not surprised that you do not know this, given the number  
of times I have explained it and related supporting facts.  (Joe is  
getting tired of the repetition).

This behavior is established since it was decided in DOM Level 1, at  
which time other Netscape DOM developers represented that browser,  
largely wrote the level 1 standard, and at that time I was  
representing Java DOM development, before I was hired at Netscape.   
These facts should be mostly evident from a reading of the standard's  
contributors section for the respective documents.

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

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 have been responding to a quite combative tone, questioning, for  
example, credentials and whether there was consideration of any HTML  
browser in the decisions, like you are the only one who has ever  
tried to write a compatible browser before or like the current state  
of the implementation hasn't drifted over the years independently  
over many years from a specification that could have been easily  
implemented at any time since then.

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

Your observation is flawed.  Just because they agree and vote to  
approve the standard doesn't mean they actually implement every  
detail.  How do you take the consensus of any company of developers?   
You cannot.  You take the consensus of their representatives and even  
then it is far from perfect, but unless the result cannot be  
implemented reasonably, I believe it should be implemented. Whenever  
there is an issue that the representative is not sure of, he is asked  
to go back and ask his developers.

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.

The browsers behavior can change from one release to the next and  
then everyone following the leaders instead of the standard suddenly  
calls the new behavior "historical" since they want to justify it,  
which may well have happened in the case of getAttribute.  DOM Level  
1 was heavily written by the browser writers.  No Java DOM writer  
would have preferred the return value of a String to a null.

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

Are you being sarcastic/combative again, or seriously thinking I was  
suggesting applying HTML parsing technology to javascript?  It is  
possible to develop strict and non-strict modes of operation and  
intelligently or even manually adapt between them as I explicitly  
suggested, and I am very confident that other approaches are possible  
as well, similar in spirit to those developed with respect to other  
broken aspects of a common document, going beyond a standard.

This is like what I will advocate as the solution to anything you  
feel you have to do that deviates from the standard.  As Joe said,  
provide a deviation, but be very careful (I would add clever) and  
explicit in doing it -- and I would add provide a mode in which web  
authors can determine that their page is really broken with respect  
to the standards, because browsers are the de-facto test platform for  
web pages, and presently do a very poor job for testing the very  
compliance a good web relies upon which they in turn rely on.

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.

That is a line of questioning which, unlike your wanting to just  
change a standard because of presumed poor implementation, could  
actually produce a change in the test suite you are so concerned  
about and requires no real change in the standard at all -- at most a  
word of clarification.  It probably has significantly more hope than  
your attack, and all it took was strait-forward rereading the words  
of the specification, which I hadn't read for a while now.

> 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.  But you have heard that many times before with little  

This change is not without significant impact to the intent of the  
consensus of the authors of that standard, unless it happens to be  
already justified by the language of the standard as written today,  
which I am currently investigating.

Ray Whitmer
Received on Saturday, 3 December 2005 02:05:25 UTC

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