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

Re: [dom3core] getAttribute

From: Ray Whitmer <ray@personallegal.net>
Date: Wed, 7 Dec 2005 08:46:45 -0700
Message-Id: <29939D6C-793F-45C9-A5E6-A53DDE55B698@personallegal.net>
To: DOM mailing list <www-dom@w3.org>

On Dec 6, 2005, at 1:55 PM, Brendan Eich wrote:

>    Then, after adoption, IE unilaterally changed it,
> This is not so.  IE always implemented an odd mixture of nullable  
> string valued properties and non-nullable string-valued properties  
> (which when missing are returned as ""), and furthermore mapped  
> properties to attributes directly, via getAttribute.
> So this has everything to do with backward compatibility going back  
> to IE 4.  The Mozilla experiment that you describe was much later,  
> and suffered the nullability confounder.  I just spoke with Johnny  
> Stenback about this and he said there may have been confusion when  
> testing IE between nullable and non-nullable attributes mapped from  
> DOM JS properties.

I readily accept that Johnny knows much more about this history and  
the actual compatibility issues than I, and it is good that we are  
getting a more-informed discussion now, discarding my own  
inaccuracies and those of others.

My knowledge of the details of exactly why they decided this one this  
way and then decided ultimately not to follow it was less accurate  
than I thought.  I have also seen all kinds of bizarre attributes  
returned from IE, especially when enumerating, but I didn't know that  
was historical behavior.  I believe (but I could be mistaken) I have  
worked with some versions of IE where no unsupported attributes could  
be attached in the first place to elements, so the null did not  
indicate that the attribute was not specified, but rather that it was  
not supported by the DOM implementation.  It is clear that IE returns  
non-null often for unspecified attributes.

As for real backwards compatibility, it is less than obvious how an  
implementation that returns nulls for unspecified attributes would  
seem compatible with an implementation that returns a strange mixture  
and possibly does not allow, in some versions, any unsupported  
attributes to be detected, whether present or not.

It was certainly not obvious to the DOM Experts representing the  
respective companies for Level 0/1 working for years trying to get  
this right.  If any had said we cannot implement this and maintain  
backwards compatibility, but if we return nulls, we can, I believe   
it would have been specified however it needed to be specified to be  
compatible with level 0 (the status quo).

I believe it is still a fact that it was implemented as agreed upon  
and then reverted in Mozilla when Mozilla got the ability to return  
nulls and strings from the same API, but to the best of my knowledge  
Mozilla has never tried to return empty string for IE supported and  
null for unsupported attributes (and the supported ones would seem  
more commonly used with respect to getAttribute).

Ray Whitmer
Received on Wednesday, 7 December 2005 15:47:05 UTC

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