[whatwg] WebIDL vs HTML5 storage changes

[Maciej Stachowiak]

On May 20, 2008, at 2:00 PM, Ian Hickson wrote:

> On Mon, 19 May 2008, Maciej Stachowiak wrote:
>> On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote:
>>
>>> If "storage.keyName = 'value';" can create a new storage item
>>> (persistently), won't authors expect "delete storage.keyName;" to
>>> remove it (persistently), as a matter of consistency?
>>>
>>> If overloading "delete" is too quirky or too hard to implement, then
>>> it seems none of the other shorthands should be allowed either.
>>
>> Many objects in the DOM implement custom name getters (for instance
>> NodeList) and a few even implement custom name setters
>> (CSSStyleDeclaration, at least the way it is done in WebKit) but no  
>> one
>> has clamored for a custom deleter or expected delete to work "as a
>> matter of consistency" or been confused that "style.opacity = 0" is
>> allowed but "delete style.opacity" is not. So I would say the  
>> available
>> evidence argues against your conclusions.
>
> The difference is that "style.opacity = 0" doesn't remove "opacity"  
> from
> the "style" object but "storage.removeItem('opacity')" _does_ remove
> "opacity" from the "storage" object.

Yes, the analogy to storage.removeItem() would be  
style.removeProperty(). You can't do "delete style.opacity" instead of  
"style.removeProperty('opacity')" and as far as I can tell, no one has  
ever asked to be able to use delete on style, or been especially  
confused that they couldn't.

> Originally, I wanted Storage objects to be indistinguishable from  
> Object
> objects in JS, and native hash or collection objects in other  
> bindings.
> Conceptually, that's what these objects are -- native name/value pair
> collections that happen to be mapped to non-volatile storage (or  
> somewhat-
> volatile storage, in the case of sessionStorage).

Normal objects don't fire DOM events when you change their properties  
(I imagine the same may be true of native hash objects in at least  
some languages), so the indistinguishability only goes so far.

> I'd also like the "delete" operator to work on DOMStringMap (for the
> dataset object -- calling 'delete' on that has the side-effect of  
> removing
> the underlying attribute) and UndoManager (where the side-effect is to
> remove the entry and renumber the following entries, so maybe that's  
> not
> such a good idea after all), for what it's worth. If we want to decide
> that we're not supporting this, we should decide that before
> implementations of those come about.

Those both sound suboptimal to me. UndoManager because it remove more  
than the one item, and DOMStringMap because (a) you can't delete from  
NamedNodeMap to remove an attribute so it would be inconsistent and  
(b) removing an attribute causes a mutation event to fire and thus  
runs arbitrary code (creating the same problem of 'delete' running  
arbitrary code as Storage).

> For DOMStringMap, my intention was to not provide methods at all,  
> and only
> provide the JS-native mechanisms.

A bold choice, but I would not recommend it as the sole available  
mechanism.

Regards,
Maciej