Note for DOM L3 Core SE

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Note for DOM L3 Core SE

Travis Leithead

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.

Travis Leithead - OM Program Manager - Internet Explorer



Reply | Threaded
Open this post in threaded view
|

Re: Note for DOM L3 Core SE

Maciej Stachowiak


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


These two issues are Safari's only failures in the official DOM Level  
1 Core test suite. I believe neither of these failures can be fixed  
without significantly breaking web compatibility.

Regards,
Maciej



Reply | Threaded
Open this post in threaded view
|

Re: Note for DOM L3 Core SE

Jonas Sicking-2

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

Reply | Threaded
Open this post in threaded view
|

Re: Note for DOM L3 Core SE

Maciej Stachowiak


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