- From: Ray Whitmer <ray@personallegal.net>
- Date: Wed, 7 Dec 2005 08:46:45 -0700
- 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