[whatwg] WebIDL vs HTML5 storage changes
beidson at apple.com
Mon May 19 16:52:35 PDT 2008
Pardon the length of my reply, I probably put more effort into it than
I should've... ;)
I'm unsure if you have the proper background with the Storage
interface that is in question here. I'm guessing that the reason that
Firefox 2 and IE8 support the "modified" behavior of delete for
Storage items is because the "way of thinking about Storage items"
we're trying to get across meets most of the expectations of
manipulating properties that you lay out below.
On May 19, 2008, at 3:18 PM, Geoffrey Garen wrote:
> very* weird, and therefore not a "useful shorthand."
> means anything else.
The spec makes it clear that storage items and properties on the
Storage object are interchangeable.
`storage.foo = "bar"` happens to be equivalent to
`storage.setItem("foo", "bar")`, but is also no different from
`someRandomObject.foo = "bar"` as far as keeping a collection of
properties on an object.
This also applies for enumeration, etc.
Equivalently and more relevant to the discussion, `delete storage.foo`
happens to be equivalent to `storage.removeItem("foo")`, but is also
*little* different from `delete someRandomObject.foo`
> For example, "delete node.parentNode" attempts to remove the
> "parentNode" property from "node". It does not remove "parentNode"
> from the document or anything like that.
> "delete window" attempts to remove the "window" property from the
> global object. It does not close the window or anything like that.
In the SessionStorage case, this applies with zero caveats. In the
LocalStorage case, it applies with the caveat that "all of the
properties you set on this object will still be on this object's
analog the next time you restart the browser and come back to this page"
And that's the really weird thing, I think - window.localStorage can
not temporary. It gets created once and maintains it's state over
mold when you get into that mindset.
Neither IE8 or FFX have implemented LocalStorage in a release yet, so
perhaps they would not support the syntax for LocalStorage, and only
support it for SessionStorage. Of course that would be even weirder,
having 2 concrete implementations of the same interface have "API
> In other words, you can be certain that "delete" is a simple
> operation with a consistent side-effect.
> about objects that might or might not change the behavior of the
> "delete" operator.
Is the behavior of the delete operator "remove the property from the
object" or is it actually "remove the property from the object with
zero other detectable side effects"?
> One reason i would find it very difficult is that operator
> this one API, I would need to understand a vast corpus of
> programming language goobery that is not at all covered in any
I think this is a pretty shameful exaggeration ;)
> Another reason I would find it very difficult is that the overloaded
> meaning of "delete" here ("remove persistent storage from disk") is
> far afield from the original meaning ("remove interface from
> temporary object in memory").
The overloaded meaning of "delete" here is "remove interface from
temporary object in memory, as well as the persistent record of its
existence." Still different from the original meaning, but not "far
> To give you an analogy, even in C++, where you're allowed to
> overload operator delete, if you overloaded operator delete to mean
> "do not free this object's memory, but do delete the file it
> references from the file system", well, let's just say that your
> patch would not pass code review with any of your four reviewers :).
But if you overloaded the delete operator to free the object's memory
*and* delete its referenced files from the file system, you'd be using
the operator overloading in its intended capacity.
> I am not sure if any JS decoration or collection libraries depend on
> the canonical behavior of operator delete, but if they do, I would
> hate for them all to have to ship with the asterisk, "BEWARE: do NOT
> use this decoration / collection library with that one weird DOM
> object that interprets 'delete' to mean 'remove important data from
> the user's disk'". Oy!
At the same time, why not be concerned that such a collection library
happens to expose the exact same API interface that the Storage object
exposes, and now that library should carry the same warning saying
"BEWARE: do NOT use this collection library with that one weird DOM
object that interprets 'clear()' to mean 'remove important data from
the user's disk'?
The fact that we're giving scripts the ability to directly manipulate
data on the users disk is already a jump-off-a-bridge as far as I'm
concerned. Shouldn't a script writer using LocalStorage use due
diligence to make sure his data is actually safe as expected?
A few final thoughts...
Despite appearances to the contrary, I'm not strongly in favor of
keeping this syntax or standardizing it. I'm just not nearly as blown
away by how weird this seems, and can easily spot the motivations
FFX2+ and IE8 had for adding this custom behavior.
I suppose another important bit of historical information is that when
FFX originally implementing this, the world of DOM storage was quite
different - there was SessionStorage and there was GlobalStorage.
SessionStorage doesn't have any of this nasty "persistence"
requirement that fuels this discussion, and GlobalStorage wasn't
exactly the same interface and therefore doesn't even suffer the
`delete` operator problem.
My big concern is that there is no good outcome here without the
standard stepping in to specify, and even then there might not be a
good outcome. Possible scenarios:
1-The spec doesn't add the delete behavior. Firefox2 and IE8 both
drop it, breaking scripts written in the past, but allowing for a
2-The spec doesn't add the delete behavior. Firefox2 and IE8 do NOT
drop it from SessionStorage, to not break past scripts. No new
browser implements it. New compatibility problem introduced to the
web, meaning a minor failure in the whole intention of the spec.
3-The spec doesn't add the delete behavior. Firefox2 and IE8 *add* it
to their LocalStorage implementations, possibly bringing up the demons
that Geoff suggests. New compatibility problem introduced to the
web, even more severe than scenario #2, meaning an even greater
failure in the whole intention of the spec.
4-The spec adds it for SessionStorage only. None of the above
concerns apply because it's temporary, anyway. IE8 and FFX hold the
course, other browsers add it for SessionStorage as well. All
browsers act the same, which is great. But the bizarre
incompatibility between SessionStorage and LocalStorage, which are
supposed to have identical interfaces, rears its ugly head on the web.
5-The spec adds it for both Session and LocalStorage. IE8 and FFX
adopt. Other browsers adopt. There's a standard that everyone
follows, no past scripts are broken, and there's compatibility going
forward. It is possible that the nonstandard delete behavior will
cause a problem with someone's assumptions about the temporary nature
of objects and properties.
Of the above scenarios, none are perfect. If we just ignore the
issue, though, and WebKit revert's it's change which added the
property, then #2 or #3 are the outcome, and they are my *least*
favorite options. :)
More information about the whatwg