Re: Note for DOM L3 Core SE

On Jun 8, 2008, at 11:35 PM, Jonas Sicking wrote:

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

The way out in this case is to fix the spec, in my opinion. Which  
hopefully we will do. Fortunately, I think these two issues may be the  
only two hard Web incompatibilities in all of DOM Core, which is not  
bad compared to other specs from the same era.

  - Maciej

Received on Monday, 9 June 2008 07:49:55 UTC