Jonas Sicking wrote:
On Tue, Sep 8, 2009 at 1:38 PM, Chris Jones<cjo...@mozilla.com> wrote:
No one has responded directly to my original proposal of making
|window.localStorage === undefined| until |window.transaction| or whatever
has been accessed. Unlike your proposal and a similar one from Jeremy, mine
is a "safe" (non-racy) way for spec-compliant UAs to "bend" backwards
compatibility without explicitly breaking it.
How is that not breaking compatibility? Any existing pages will
directly access window.localStorage to read/write data. Such pages
would break with your proposal, no?
I think I haven't been explaining my proposal clearly enough. Let me
try to err on the other side of brevity. Sorry if this is too pedantic.
Currently, UAs either (i) support localStorage or (ii) don't. Web apps
using localStorage must therefore determine whether the UA they're
running in supports localStorage, and adjust their behavior accordingly.
If they don't, they won't run in type (ii) UAs.
So how do web apps implement this check? If I were implementing it, I
would test |window.localStorage === undefined|. I have no clue how web
devs actually implement it; I solicited feedback from them in earlier posts.
Assuming that web apps test for |window.localStorage === undefined|,
then let's explore the two possibilities for changing the localStorage
API to include transactions. If the spec were to add transactional
localStorage, then UAs in the field would then fall into three classes
(i) support transactional localStorage [compliant]; (ii) support
non-transactional localStorage [non-compliant]; (iii) don't support
localStorage at all [non-compliant]. Web apps would also fall into
three classes (a) use transactional localStorage [compliant]; (b) use
non-transactional localStorage [non-compliant]; (c) don't use
localStorage [NA].
Note that web app type (c) is irrelevant to the discussion, since
changes to the localStorage API don't affect them.
With my proposal, a web app that tests whether localStorage is available
with |window.localStorage === undefined| would conclude that it's not,
because that object would not be available until |window.transaction| or
whatever was accessed. In Jeremy's and Benjamin's proposals, a web app
using that would check would conclude that window.localStorage *is*
available.
Only type (b) web apps are affected by this difference. In my proposal,
in type (i) browsers, type (b) web apps would conclude that
localStorage was not supported and thus those web apps would not try to
use it. In other words, they would *not* break, just not use
localStorage. In Jeremy's and Benjamin's proposals, type (b) web apps
would conclude that localStorage *is* supported, and would use it in a
racy way (outside of transactions), to the detriment of themselves and UAs.
Type (c) web apps would need to use the check |window.transaction ===
undefined| to determine whether *transactional* localStorage was
supported, and thus aren't affected by either proposal.
If this explication isn't clear, please let me know and I will construct
a compatibility matrix based on (a), (b), (c), and (i), (ii), (iii).
The |window.localStorage === undefined|-check assumption is a big one
(!). If that's not how the compatibility check is done in the wild,
then my proposal won't ameliorate the breakage of type (b) web apps.
Cheers,
Chris
