Maciej Stachowiak wrote:
On Jun 6, 2008, at 2:20 PM, Travis Leithead wrote:
While implementing some improvements to getAttribute in IE8, we
actually checked in code that is conformant to what the spec says
about the return value:
Return Value
DOMString
The Attr value as a string, or the empty string if that attribute does
not have a specified or default value
Once this code was in, we immediately hit app and site compat problems
because we always returned a string--an empty string--if the
"attribute [did] not have a specified or default value".
As it turns out in practice, all browsers actually implement this a
slightly different way: they return the value as a string, or null if
the attribute does not have a specified or default value. In other
words, if there is no entry for the requested attribute in the
NamedNodeMap, then null is returned.
IE8 is being fixed to be conformant with what everyone else has
implemented, I just thought I would pass this along to whomever is
doing the DOM L3 Core Second Edition so that it might be recorded in
that spec, an errata, or so that we can discuss.
Anne and I suggested an errata for this a few years back, but the DOM
folks were not receptive at the time, out of consideration for
server-side Java DOM implementations:
http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0011.html
http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0025.html
See the thread for more discussion.
I also at the time raised another compatibility issue that I thought
should be fixed in errata:
http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0024.html
The short version is that DOM forbids inserting nodes into a different
document than their ownerDocument, but browsers allow it (in at least
some cases).
Yup, this is a bad situation indeed. Basically browsers are stuck with
no good way out: Be compatible with the spec, or be compatible with the
web. Of course any serious web browser is going to choose the latter.
/ Jonas
