[whatwg] WebIDL vs HTML5 storage changes

[Maciej Stachowiak]

On May 18, 2008, at 3:18 PM, Brady Eidson wrote:

> A little while ago, this change - http://html5.org/tools/web-apps-tracker?from=1429&to=1430 
>  - was meant to "update the spec for consistency with WebIDL"
>
> In this change, the following passage was removed from the Storage  
> section:
>
> "In the ECMAScript DOM binding, enumerating a Storage object must  
> enumerate through the currently stored keys in the list the object  
> is associated with. (It must not enumerate the values or the actual  
> members of the interface). In the ECMAScript DOM binding, Storage  
> objects must support dereferencing such that getting a property that  
> is not a member of the object (i.e. is neither a member of the  
> Storage interface nor of Object) must invoke the getItem() method  
> with the property's name as the argument, and setting such a  
> property must invoke the setItem() method with the property's name  
> as the first argument and the given value as the second argument."
>
> Shorty thereafter, the declaration of the Storage interface was  
> changed to the following:
>
> interface Storage {
>    readonly attribute unsigned long length;
>    [IndexGetter] DOMString key(in unsigned long index);
>    [NameGetter] DOMString getItem(in DOMString key);
>    [NameSetter] void setItem(in DOMString key, in DOMString data);
>    [XXX] void removeItem(in DOMString key);
>    void clear();
> };
>
> I assumed that the WebIDL descriptions of [IndexGetter],  
> [NameGetter], and [NameSetter] would keep the specified  
> functionality in tact, but it appears this is *not* the case.
> Or by reading http://dev.w3.org/2006/webapi/Binding4DOM/ I can't  
> find where it is the case...
>
> Does someone know what is up with this?
>
> While I'm on the topic, I'm also curious about that [XXX] placeholder.
> There's a bug in WebKit's bugzilla pointing out that the IE8 beta  
> and Firefox 2 both support  `delete storage.keyName` syntax as an  
> alias for `storage.removeItem(keyName)`
> I'm taking a guess here and assuming supporting the `delete` syntax  
> is the implied concept behind [XXX]

WebKit's JavaScript engine doesn't currently have the ability to run  
custom code when a property is deleted. It would be a significant  
challenge to add this capability and possibly a performance  
regression; and no other DOM-related spec requires this, even when  
there is NameGetter or IndexGetter behavior. For example NodeLists and  
HTMLCollections do not let you delete by name to remove the item (I'm  
not sure what that would even mean). So I'd prefer not to have to  
introducethis concept just for this one case.

Regards,
Maciej