FWIW, I wrote my tests using IE7, not IE8.
The original argument I was countering was "browsers currently enforce
synchronous access to cookies, so we can't add asynchronous access via
workers because that will break existing sites". Clearly, this argument was
incorrect, since the core assumption a
On Sun, Mar 22, 2009 at 10:13 AM, Jonas Sicking wrote:
> It's the vendors that have exposed their users to this inconsistency
> that you should ask. Or maybe sites that use document.cookie a lot and
> that have a lot of chrome or IE8 users. Though both of those browsers
> might be too new to have
On Mon, Mar 23, 2009 at 8:07 AM, Michael Nordman wrote:
> I don't see how denying workers solves the problem. In a multi-threaded
> browser, this has to be resolved reasonably even in the absence of workers.
>
It has to be resolved in a way that doesn't expose asynchronous cookie or
localStorage
If you deny workers, you can enforce exclusive access to localStorage by
applying a lock that extends from the first access of localStorage until the
script re-enters the event loop. Page script is guaranteed to re-enter the
event loop fairly quickly (lest it trigger the browser's "this script is
t
On Sun, Mar 22, 2009 at 11:53 AM, Aaron Boodman wrote:
> On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson wrote:
> > I've thought about this more, and I'm afraid that if you start making the
> > API cumbersome (forcing only async access) then apps are just going to
> use
> > document.cookies instea
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson wrote:
> I've thought about this more, and I'm afraid that if you start making the
> API cumbersome (forcing only async access) then apps are just going to use
> document.cookies instead of localStorage. I'd hate to see us radically
> change the API to
On Sun, Mar 22, 2009 at 11:21 AM, Drew Wilson wrote:
> The problem is that .length is basically useless without some kind of
> immutability guarantees.
Understood, and when you need that guarantee it would be available via the
getLocalStorage(callback) API.
>
> I've thought about this more, a
2009/3/22 Ian Hickson :
> On Sat, 21 Mar 2009, Giovanni Campagna wrote:
>>
>> Now I would like to ask:
>> are there any major differences that requires the W3C / WHATWG to
>> publish an other specification, just for HTML5, instead of just
>> referencing the IRI-bis draft or the LEIRI working group
The problem is that .length is basically useless without some kind of
immutability guarantees.
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to use
document.cookies instead of localStorage. I'd hate to s
On Sat, Mar 21, 2009 at 3:25 PM, Aaron Boodman wrote:
> On Sat, Mar 21, 2009 at 1:51 PM, Jonas Sicking wrote:
> > The problem with synchronously grabbing the lock is that we can only
> > ever have one feature that uses synchronous locks, otherwise we'll
> > risk dead-locks.
> >
> > Say that we m
Ian Hickson (2009-02-13):
There are three of these attributes so far:
autocomplete = on/off
contenteditable = true/false
draggable = true/false
It would be nice, actually, from an author perspective at least, if
all of these worked for all applicable attributes:
*
*
11 matches
Mail list logo
