W3C home > Mailing lists > Public > public-webapi@w3.org > June 2008

Re: Note for DOM L3 Core SE

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 9 Jun 2008 00:49:12 -0700
Cc: Travis Leithead <travil@windows.microsoft.com>, "public-webapi@w3.org" <public-webapi@w3.org>, Ian Hickson <ian@hixie.ch>
Message-Id: <975D3F3F-A189-47D4-A2CA-071180CD3828@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC