Re: [whatwg] HTML Cookie API
On Tue, 23 Feb 2010, Adam Barth wrote: > > The document.cookie API is kind of terrible. Web developers shouldn't > have to parse a cookie-string or prepare a properly formated > set-cookie-string. Here's a proposal for an HTML cookie API that isn't > as terrible: > > https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en > > I'd like to propose we include this API in a future version of HTML. As > always, feedback welcome. The incremental benefit of this seems pretty minimal, considering that there are widely available libraries that provide better APIs for cookies already, especially since as I understand it we want to move people off cookies where possible. This is quite a lot of surface area (meaning implementation cost, testing cost, potential bugs, tutorial costs, etc), and introduces quite a lot of authoring complexity (e.g. having to do everything asynchronously), for such a minimal incremental benefit (responsiveness and not having to use a library once this is widely deployed in the browsers you care about). All things considered, I think we should probably wait until we have addressed more fundamental problems with the platform before adding something like this. Having said that, if browser vendors think this is something worth implementing today, then the above is a pretty good stand-alone spec. It would be reasonable IMHO for this API to be specified separately, e.g. through the Web Apps WG. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML Cookie API
On Fri, Feb 26, 2010 at 12:20 PM, Darin Fisher wrote:
> On Fri, Feb 26, 2010 at 12:04 PM, Diogo Resende
> wrote:
>>
>>
>> > No. pushCookies would be a way of pushing cookies to the
>> > current js and
>> > then you could call getCookie several times without defining a
>> > callback.
>> > It would be almost like:
>> >
>> > document.observe("cookieload", myAppLoad)
>> >
>> >
>> > Right. My point was that you could implement pushCookies on top of
>> > Adam's API.
>> >
>> >
>> > -Darin
>>
>> Agree. Just like you could implement Adam's API on top of current
>> browsers cookies spec :P
>>
>
>
> No, I don't think that is possible. Adam's spec reveals a lot of extra
> information that "document.cookie" does not return. For example, it exposes
> domain and expiry information.
> But, I think your point was that it would be possible to simulate an
> asynchronous API on top of a synchronous one. I agree that is possible, but
> it would not perform very well.
Another problem is that some current browsers do not implement
document.cookie in a non-racy way. So while you could implement Adams
API, you couldn't guarantee that it wouldn't be racy. However
implementations should be able to implement Adams asynch API with no
race problems.
/ Jonas
Re: [whatwg] HTML Cookie API
On Fri, Feb 26, 2010 at 12:04 PM, Diogo Resende wrote:
>
>
> > No. pushCookies would be a way of pushing cookies to the
> > current js and
> > then you could call getCookie several times without defining a
> > callback.
> > It would be almost like:
> >
> >document.observe("cookieload", myAppLoad)
> >
> >
> > Right. My point was that you could implement pushCookies on top of
> > Adam's API.
> >
> >
> > -Darin
>
> Agree. Just like you could implement Adam's API on top of current
> browsers cookies spec :P
>
>
No, I don't think that is possible. Adam's spec reveals a lot of extra
information that "document.cookie" does not return. For example, it exposes
domain and expiry information.
But, I think your point was that it would be possible to simulate an
asynchronous API on top of a synchronous one. I agree that is possible, but
it would not perform very well.
Regards,
-Darin
Re: [whatwg] HTML Cookie API
> No. pushCookies would be a way of pushing cookies to the
> current js and
> then you could call getCookie several times without defining a
> callback.
> It would be almost like:
>
>document.observe("cookieload", myAppLoad)
>
>
> Right. My point was that you could implement pushCookies on top of
> Adam's API.
>
>
> -Darin
Agree. Just like you could implement Adam's API on top of current
browsers cookies spec :P
Re: [whatwg] HTML Cookie API
On Fri, Feb 26, 2010 at 10:56 AM, Diogo Resende wrote:
>
>
> > What about something like:
> >
> > document.pushCookies(function () {
> >// cookies have been pushed to the js process
> >var x = document.getCookie("x");
> >// whatever...
> > });
> >
> >
> > This seems similar to Adam's proposed document.getAllCookies.
> >
> >
> > -Darin
>
> No. pushCookies would be a way of pushing cookies to the current js and
> then you could call getCookie several times without defining a callback.
> It would be almost like:
>
>document.observe("cookieload", myAppLoad)
>
>
Right. My point was that you could implement pushCookies on top of Adam's
API.
-Darin
Re: [whatwg] HTML Cookie API
> What about something like:
>
> document.pushCookies(function () {
>// cookies have been pushed to the js process
>var x = document.getCookie("x");
>// whatever...
> });
>
>
> This seems similar to Adam's proposed document.getAllCookies.
>
>
> -Darin
No. pushCookies would be a way of pushing cookies to the current js and
then you could call getCookie several times without defining a callback.
It would be almost like:
document.observe("cookieload", myAppLoad)
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 10:48 PM, James Robinson wrote: > On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth wrote: >> >> On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking wrote: >> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >> >> The document.cookie API is kind of terrible. Web developers shouldn't >> >> have to parse a cookie-string or prepare a properly formated >> >> set-cookie-string. Here's a proposal for an HTML cookie API that >> >> isn't as terrible: >> >> >> >> >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> >> >> I'd like to propose we include this API in a future version of HTML. >> >> As always, feedback welcome. > > The "array-like object containing the Cookies for the document" should be a > read-only copy of a set of objects that represent all the applicable cookies > at some point between the request and the response. This needs to be really > clear and it needs to be clear what happens if a user, say, calls > setCookie() in the middle of iterating through the array-like object (imho > the iteration should be unaffected). Done. > It's probably best to specify the ordering of Cookies in this array-like > object to match rfc2965's ordering rules so that users of the API don't have > to implement this ordering themselves. I've specced that they should be ordered as the would appear in document.cookie. I doubt that matches RFC 2965 because RFC 2965 differs significantly from reality. (Although hopefully it will match the new cookie spec.) > Accessing cookies from script is inherently racy - there is no way to > promise that the browser will or will not return a cookie being set by some > HTTP response arriving "at the same time" as the getCookies() call. There's > nothing really you can do about this but I think that this fact should be > highlighted in the spec. I've added the text "this API provides a snapshot of the data in the cookie store at some time". > If a U-A's privacy settings disallow script from accessing cookies, there > should be some clear behavior. It looks like a U-A could make setCookie() a > no-op and always invoke the getCookies() callback with an empty list now - > should that be specified? I've added an error callback to setCookie for this case. For getCookie, we can return an empty array. Note that there's already a DOM property for querying whether cookies are enabled. Adam
Re: [whatwg] HTML Cookie API
On Thu, Feb 25, 2010 at 6:54 AM, Diogo Resende wrote:
> On Wed, 2010-02-24 at 11:21 -0800, Darin Fisher wrote:
> > For reference, reading document.cookie has measurable performance cost
> > in Chromium since the cookie jar lives in a process separate from the
> > process running JavaScript. We could have minimized this cost by
> > caching the cookies locally, but then there are cache coherency
> > issues.
> >
> >
> > I think the cookie APIs should have been asynchronous from the start.
> > Whenever an API is backed by I/O, asynchronous should be the rule.
> >
> >
> > -Darin
>
> What about something like:
>
> document.pushCookies(function () {
>// cookies have been pushed to the js process
>var x = document.getCookie("x");
>// whatever...
> });
>
>
This seems similar to Adam's proposed document.getAllCookies.
-Darin
Re: [whatwg] HTML Cookie API
On Wed, 2010-02-24 at 11:21 -0800, Darin Fisher wrote:
> For reference, reading document.cookie has measurable performance cost
> in Chromium since the cookie jar lives in a process separate from the
> process running JavaScript. We could have minimized this cost by
> caching the cookies locally, but then there are cache coherency
> issues.
>
>
> I think the cookie APIs should have been asynchronous from the start.
> Whenever an API is backed by I/O, asynchronous should be the rule.
>
>
> -Darin
What about something like:
document.pushCookies(function () {
// cookies have been pushed to the js process
var x = document.getCookie("x");
// whatever...
});
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 8:49 PM, Darin Fisher wrote: > Some other random comments: > 1- Perhaps deleteCookie should also take an optional error callback. Done. It's a bit strange, but deleteCookie can fail in third-party contexts. > 2- Is it possible for setCookie to be used to set a http-only cookie? That > could be an interesting use case. Some browsers allow this, but others don't. IMHO, it doesn't matter much for security, but some folks think that it does. Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 6:08 PM, Adam Barth wrote: > On Wed, Feb 24, 2010 at 5:00 PM, Nicholas Zakas > wrote: > > Even though there can be multiple cookies with the same name on a single > document, this most frequently occurs due to error rather than intention. > I've never received a YUI bug report about this occurrence though I have > considered returning an array of values instead of just the first value in > this case. I might just go do that now. :) > > > > My initial comment still remains: retrieving the value of a single named > cookie seems to be a much more common use case than retrieving all cookies. > You can choose to solve the duplicate cookie name issue in a number of ways, > but not providing a way to access a cookie by name seems like a flaw in this > design. > > Done. I've made the API return the first cookie that matches the > specified name. If a web developer wants to get all the cookies, I've > added a getAllCookies() API. > > Adam > Some other random comments: 1- Perhaps deleteCookie should also take an optional error callback. 2- Is it possible for setCookie to be used to set a http-only cookie? That could be an interesting use case. -Darin
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 5:00 PM, Nicholas Zakas wrote: > Even though there can be multiple cookies with the same name on a single > document, this most frequently occurs due to error rather than intention. > I've never received a YUI bug report about this occurrence though I have > considered returning an array of values instead of just the first value in > this case. I might just go do that now. :) > > My initial comment still remains: retrieving the value of a single named > cookie seems to be a much more common use case than retrieving all cookies. > You can choose to solve the duplicate cookie name issue in a number of ways, > but not providing a way to access a cookie by name seems like a flaw in this > design. Done. I've made the API return the first cookie that matches the specified name. If a web developer wants to get all the cookies, I've added a getAllCookies() API. Adam
Re: [whatwg] HTML Cookie API
Even though there can be multiple cookies with the same name on a single
document, this most frequently occurs due to error rather than intention. I've
never received a YUI bug report about this occurrence though I have considered
returning an array of values instead of just the first value in this case. I
might just go do that now. :)
My initial comment still remains: retrieving the value of a single named cookie
seems to be a much more common use case than retrieving all cookies. You can
choose to solve the duplicate cookie name issue in a number of ways, but not
providing a way to access a cookie by name seems like a flaw in this design.
Of course, if the main use case you're concerned about is retrieving all
cookies, then feel free to disregard this feedback.
-Nicholas
__
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Wednesday, February 24, 2010 1:07 PM
To: Nicholas Zakas
Cc: Darin Fisher; whatwg
Subject: Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote:
> I like the idea of creating an easier way to deal with cookies (which is why
> I wrote the YUI Cookie utility way back when). The thing that seems to be
> missing in your proposed API is what I consider to be the most common use
> case: retrieving the value of a single cookie. There's not many times when I
> need to get every single cookie that's available on the page, but there are
> plenty of times when I want to check the value of a single cookie. Using your
> API, getting the value of a single cookie with a known name becomes:
>
> document.getCookies(function(cookies) {
> for (var i=0; i < cookies.length; ++i){
> if(cookies[i].name == "my_cookie_name"){
> doSomething(cookies[i]);
> }
> }
> });
>
> That seems like a lot of work just to retrieve a single cookie value.
The problem is there can be multiple cookies with the same name for a
given document. The YUI Cookie utility seems to assume there's only
one. We could add a facility for filtering the results of getCookies,
but that's easy enough to do correctly in JavaScript.
Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:30 PM, Garrett Smith wrote: > On Wed, Feb 24, 2010 at 4:17 PM, Adam Barth wrote: >> On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith >> wrote: >>> Instead of "array like", I would like to rather have a NamedCookieMap, >>> which is sort of like a NamedNodeMap that the cookies can be retrieved >>> by an item or namedItem. >> >> That API design assumes that there's only one cookie with a given name >> in each cookie-string. Unfortunately, that is not a valid assumption. > > That is only true in that that example assumes that each cookie is > named. It would be entirely possible for the value to be instead a > collection, as in: > > var x = document.forms[0].elements["radioName"] > > - and the result is that x could be either an element or a collection > of elements. That seems more complex than just providing a list of cookies. >>> Where is the argument for making the API async? >> >> Please see the discussion earlier in this thread. >> > Can you be more specific? I see: > > | I really think the API should be asynchronous, as to avoid the mess > | that .localStorage currently is. > > But I don't know if that's what you meant by "please see earlier". I mean looking at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/thread.html and reading the thread rooted at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025300.html. In particular, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025325.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025326.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025327.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025331.html Those messages also refer to thousands of messages about localStorage. All the synchrony issues with localStorage recur here. >>> Cookies have been synchronous for longer than I have been writing >>> javascript and to my knowledge, nobody has ever complained of that >>> being a problem. >> >> In fact, I've heard a great many complaints about this recently >> (particularly from Darin Fisher), which is part of what prompted me to >> make this proposal. > > Is there a link to that? I missed it. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025326.html ... plus personal communication. >>> Asynchronous cookies that would mean that cookie setting tests would be >>> harder. >> >> No one is suggesting removing the current document.cookie API. > > Nobody is suggesting you change your tires. Why bring it up? This API does not make it any harder to test whether setting a cookie works because you can still use whatever test you like. If we want to solve the problem of making cookie feature testing easier, we can do that. Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:30 PM, Garrett Smith wrote: > >> Where is the argument for making the API async? > > > > Please see the discussion earlier in this thread. > > > Can you be more specific? I see: > > | I really think the API should be asynchronous, as to avoid the mess > | that .localStorage currently is. > > But I don't know if that's what you meant by "please see earlier". > There have been numerous messages (well over a dozen) discussing this. If you don't see them, try checking online archives, waiting for their delivery to your mailbox, or similar. > >> Asynchronous cookies that would mean that cookie setting tests would be > harder. > > > > No one is suggesting removing the current document.cookie API. > > Nobody is suggesting you change your tires. Why bring it up? This response makes no sense at all. You expressed concern that an async API would make particular existing patterns harder to write. The response was that these existing patterns will continue to work because they rely on a synchronous API that isn't getting removed; the async API is proposed as an addition. I have no idea what your retort after that is intended to convey. PK
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:17 PM, Adam Barth wrote: > On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith wrote: >> On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >>> The document.cookie API is kind of terrible. Web developers shouldn't >>> have to parse a cookie-string or prepare a properly formated >>> set-cookie-string. Here's a proposal for an HTML cookie API that >>> isn't as terrible: >>> >>> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >>> >>> I'd like to propose we include this API in a future version of HTML. >>> As always, feedback welcome. >>> >> | Because HttpOnly cookies are inaccessible to script, the |httpOnly| >> | attribute will usually be false. >> >> Usually? When ever would HttpOnly be true? > > For example, if the HTML document is running with higher privileges > because its effective security origin isn't a (scheme, host, port) > tuple. This can occur, e.g., in Firefox when running with "chrome" > privileges. > >> Instead of "array like", I would like to rather have a NamedCookieMap, >> which is sort of like a NamedNodeMap that the cookies can be retrieved >> by an item or namedItem. > > That API design assumes that there's only one cookie with a given name > in each cookie-string. Unfortunately, that is not a valid assumption. > That is only true in that that example assumes that each cookie is named. It would be entirely possible for the value to be instead a collection, as in: var x = document.forms[0].elements["radioName"] - and the result is that x could be either an element or a collection of elements. >> Where is the argument for making the API async? > > Please see the discussion earlier in this thread. > Can you be more specific? I see: | I really think the API should be asynchronous, as to avoid the mess | that .localStorage currently is. But I don't know if that's what you meant by "please see earlier". >> Cookies have been synchronous for longer than I have been writing >> javascript and to my knowledge, nobody has ever complained of that >> being a problem. > > In fact, I've heard a great many complaints about this recently > (particularly from Darin Fisher), which is part of what prompted me to > make this proposal. > Is there a link to that? I missed it. >> Asynchronous cookies that would mean that cookie setting tests would be >> harder. > > No one is suggesting removing the current document.cookie API. Nobody is suggesting you change your tires. Why bring it up? Garrett
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:03 PM, Garrett Smith wrote: > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. >> > | Because HttpOnly cookies are inaccessible to script, the |httpOnly| > | attribute will usually be false. > > Usually? When ever would HttpOnly be true? For example, if the HTML document is running with higher privileges because its effective security origin isn't a (scheme, host, port) tuple. This can occur, e.g., in Firefox when running with "chrome" privileges. > Instead of "array like", I would like to rather have a NamedCookieMap, > which is sort of like a NamedNodeMap that the cookies can be retrieved > by an item or namedItem. That API design assumes that there's only one cookie with a given name in each cookie-string. Unfortunately, that is not a valid assumption. > Where is the argument for making the API async? Please see the discussion earlier in this thread. > Cookies have been synchronous for longer than I have been writing > javascript and to my knowledge, nobody has ever complained of that > being a problem. In fact, I've heard a great many complaints about this recently (particularly from Darin Fisher), which is part of what prompted me to make this proposal. > Asynchronous cookies that would mean that cookie setting tests would be > harder. No one is suggesting removing the current document.cookie API. You can continue to use whatever cookie setting test you're current using. Adam
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
> The document.cookie API is kind of terrible. Web developers shouldn't
> have to parse a cookie-string or prepare a properly formated
> set-cookie-string. Here's a proposal for an HTML cookie API that
> isn't as terrible:
>
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>
> I'd like to propose we include this API in a future version of HTML.
> As always, feedback welcome.
>
| Because HttpOnly cookies are inaccessible to script, the |httpOnly|
| attribute will usually be false.
Usually? When ever would HttpOnly be true?
Instead of "array like", I would like to rather have a NamedCookieMap,
which is sort of like a NamedNodeMap that the cookies can be retrieved
by an item or namedItem.
I would also rather like to see a `cookies` getter instead of
getCookies (just personally, style-wise I like that).
// Get a Cookie object or null.
var fooCook = document.cookies.namedItem("foo");
- or -
// Get a Cookie object or undefined.
var fooCook = document.cookies["foo"];
- or -
// Get a Cookie object or undefined.
var fooCookIndex = 2;
fooCook = document.cookies[fooCookIndex];
How about that?
A Cookes API makes working with cookies easier.
Working with cookies is important to support browsers that do not
implement new features such HTML 5 storage APIs.
For legacy browsers, a Cookie API can be easily emulated in script. A
common interface for new browsers and legacy browsers would have
consistent cross browser behavior and little disparity. The same
cannot be said for Storage APIs.
Where is the argument for making the API async?
Cookies have been synchronous for longer than I have been writing
javascript and to my knowledge, nobody has ever complained of that
being a problem. A common feature test is something like:
var isCookieSupported;
if(typeof document.cookie == "string") {
document.cookie = "test=1";
isCookieSupported = document.cookie.indexOf("test=1") !== -1;
}
That feature test relies on the fact that cookies are synchronous. If
the new proposed API is also synchronous, then the cookies feature
test will be possible as:-
var isCookieSupported;
if(typeof document.cookie == "string") {
document.setCookie({name: "test", value : "1"});
isCookieSupported = document.cookies.test === "1";
}
Asynchronous cookies that would mean that cookie setting tests would be harder.
Garrett
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote:
> I like the idea of creating an easier way to deal with cookies (which is why
> I wrote the YUI Cookie utility way back when). The thing that seems to be
> missing in your proposed API is what I consider to be the most common use
> case: retrieving the value of a single cookie. There's not many times when I
> need to get every single cookie that's available on the page, but there are
> plenty of times when I want to check the value of a single cookie. Using your
> API, getting the value of a single cookie with a known name becomes:
>
> document.getCookies(function(cookies) {
> for (var i=0; i < cookies.length; ++i){
> if(cookies[i].name == "my_cookie_name"){
> doSomething(cookies[i]);
> }
> }
> });
>
> That seems like a lot of work just to retrieve a single cookie value.
The problem is there can be multiple cookies with the same name for a
given document. The YUI Cookie utility seems to assume there's only
one. We could add a facility for filtering the results of getCookies,
but that's easy enough to do correctly in JavaScript.
Adam
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 12:44 PM, Nicholas Zakas wrote: > I think there’s always going to be a disconnect between browser developers > and web developers, since we’re both living in very different worlds. > > Like I said, I’m all for making cookie access more rational (as if one could > argue that it has been at all rational to this point). Right now, though, I > can’t see a benefit to switching from any of the current synchronous > approaches to an asynchronous one, as it doesn’t give me enough added > benefit. The added benefits are: 1) Higher performance because your page isn't frozen while the browser jumps across some number of threads and processes to reach the disk. 2) Fewer bugs because you don't have to parse the cookie-string / manufacture a set-cookie-string yourself. > The asynchronous approach may be the most performant and > potentially the easiest to implement, but if it’s out there and everyone is > still using document.cookie, is there really a net gain? Folks who want synchronous access to cookies can continue to use document.cookie. Folks who want to realize the benefits of the new API can use the new API. Sounds like everyone wins. Adam
Re: [whatwg] HTML Cookie API
I think there's always going to be a disconnect between browser developers and web developers, since we're both living in very different worlds. Like I said, I'm all for making cookie access more rational (as if one could argue that it has been at all rational to this point). Right now, though, I can't see a benefit to switching from any of the current synchronous approaches to an asynchronous one, as it doesn't give me enough added benefit. The asynchronous approach may be the most performant and potentially the easiest to implement, but if it's out there and everyone is still using document.cookie, is there really a net gain? -Nicholas __ Commander Lock: "Damnit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Wednesday, February 24, 2010 12:20 PM To: David Flanagan Cc: Peter Kasting; whatwg; Nicholas Zakas; Darin Fisher; Adam Barth Subject: Re: [whatwg] HTML Cookie API On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan wrote: Jeremy Orlow wrote: Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention. Well if no one is going to implement the storage mutex, then I probably need to retract my last message But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world. J I worry that this comes down to web developers who want simple APIs vs browser implementors who say we can't have them (at least not if we also want speed.) Concurrency issues are not my strong suit, but shouldn't it be possible to have safe, synchronous read-only access to cookies (caching volatile values like cookies within each thread and then clearing that cache when the thread returns to the event loop). Can't the requirement for a mutex or an asynchronous API be limited to setCookie()? >From a technical standpoint, this is very doable. And, done right, I think I could be in favor of it. But I believe the counter argument is that any relaxation of run to completion semantics is going to confuse developers and probably result in them writing racy code without realizing it. Many developers won't understand when it's safe to use the cached value vs needing to use the asynchronous interface. And if the less safe one is easier to use I agree that asynchronous interfaces have disadvantages, but as far as I can tell many of them are costs that you pay once (learning them and getting use to them) or once per app (if you handle one asynchronous call or need to use setTimeout, then probably using another won't require too much restructuring of your code). Maybe I'm just a browser developer who's completely out of touch with reality though. :-)
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan wrote: > Jeremy Orlow wrote: > > >> Also note that the spec currently has the notion of a storage mutex which >> should be taken whenever a script tries to access a cookie (or local >> storage) and is held until the script finishes. The network stack is also >> supposed to take this lock whenever getting or setting a cookie. No one has >> implemented the storage mutex or stated any intention of doing so because >> this is basically impossible today. But, if there were an asynchronous API >> that most people were using, it actually could be possible that we'd want to >> implement such a mutex since cookies would then obey run to completion >> semantics without having serious lock contention. >> >> > Well if no one is going to implement the storage mutex, then I probably > need to retract my last message > > > But yeah. Definitely any API that touches information spanning tabs (and >> probably even APIs spanning origins within those tabs) really should be >> designed in an async manor from now on. Otherwise we're just digging the >> whole deeper in terms of forcing ourselves into a single threaded world. >> >> J >> > > I worry that this comes down to web developers who want simple APIs vs > browser implementors who say we can't have them (at least not if we also > want speed.) > > Concurrency issues are not my strong suit, but shouldn't it be possible to > have safe, synchronous read-only access to cookies (caching volatile values > like cookies within each thread and then clearing that cache when the thread > returns to the event loop). Can't the requirement for a mutex or an > asynchronous API be limited to setCookie()? > >From a technical standpoint, this is very doable. And, done right, I think I could be in favor of it. But I believe the counter argument is that any relaxation of run to completion semantics is going to confuse developers and probably result in them writing racy code without realizing it. Many developers won't understand when it's safe to use the cached value vs needing to use the asynchronous interface. And if the less safe one is easier to use I agree that asynchronous interfaces have disadvantages, but as far as I can tell many of them are costs that you pay once (learning them and getting use to them) or once per app (if you handle one asynchronous call or need to use setTimeout, then probably using another won't require too much restructuring of your code). Maybe I'm just a browser developer who's completely out of touch with reality though. :-)
Re: [whatwg] HTML Cookie API
Jeremy Orlow wrote: Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention. Well if no one is going to implement the storage mutex, then I probably need to retract my last message But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world. J I worry that this comes down to web developers who want simple APIs vs browser implementors who say we can't have them (at least not if we also want speed.) Concurrency issues are not my strong suit, but shouldn't it be possible to have safe, synchronous read-only access to cookies (caching volatile values like cookies within each thread and then clearing that cache when the thread returns to the event loop). Can't the requirement for a mutex or an asynchronous API be limited to setCookie()? David
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 8:52 PM, David Flanagan wrote:
> Boris Zbarsky wrote:
>
>> On 2/24/10 1:04 PM, David Flanagan wrote:
>>
>>> If I've been following the thread correctly, the justification for an
>>> asynchronous API was that localStorage is a mess, or something like
>>> that. I'm not aware of what the issues are with localStorage
>>>
>>
>> In brief, the fact that if you have multiple threads or processes
>> rendering web pages from the same site, then they can race each other.
>>
>> could you justify an asynchronous cookie API more explicitly? This isn't
>>> a
>>> blocking I/O issue, is it? Surely browsers will have the relevant
>>> cookies already cached in memory, won't they?
>>>
>>
>> Yes, but cookies are not immutable.
>>
>> In simple use cases, a developer just wants the cookie value
>>>
>>
>> Only once? With a sync API this code:
>>
>> if (document.cookie == document.cookie) {
>>alert("pass");
>> } else {
>>alert("fail");
>> }
>>
>
> will sometimes alert "fail" depending on what other web pages are loading
>> at the same time and what their HTTP headers look like and what their
>> scripts are doing.
>>
>> -Boris
>>
>>
> [Changing the subject line back]
>
> Doesn't the HTML5 storage mutex fix this?
>
Please read my email from 30 minutes ago.
> With the storage mutex mechanism it is possible to create a safe (no way to
> observe volatility) synchronous version of getCookies(), isn't it?
Sure.
> The downside is that getCookies() might have to block while waiting for the
> mutex.
Exactly.
> But is that really a reason not to allow synchronous (blocking) access to
> cookies?
YES!
> Given that the storage mutex is already in the spec,
It's in the spec, but no one has implemented it or signaled any intention to
do so. We at Google have gone so far as to say that we will not implement
it. So, even though it's there, I'm not sure how much it means at this
point.
> doesn't it make sense to define a better synchronous API in addition to the
> new asynchronous API?
Please see all the LocalStorage discussions and then see if you still think
it's possible to do such a thing.
J
Re: [whatwg] HTML Cookie API
Boris Zbarsky wrote:
On 2/24/10 1:04 PM, David Flanagan wrote:
If I've been following the thread correctly, the justification for an
asynchronous API was that localStorage is a mess, or something like
that. I'm not aware of what the issues are with localStorage
In brief, the fact that if you have multiple threads or processes
rendering web pages from the same site, then they can race each other.
could you justify an asynchronous cookie API more explicitly? This
isn't a
blocking I/O issue, is it? Surely browsers will have the relevant
cookies already cached in memory, won't they?
Yes, but cookies are not immutable.
In simple use cases, a developer just wants the cookie value
Only once? With a sync API this code:
if (document.cookie == document.cookie) {
alert("pass");
} else {
alert("fail");
}
will sometimes alert "fail" depending on what other web pages are
loading at the same time and what their HTTP headers look like and what
their scripts are doing.
-Boris
[Changing the subject line back]
Doesn't the HTML5 storage mutex fix this?
With the storage mutex mechanism it is possible to create a safe (no way
to observe volatility) synchronous version of getCookies(), isn't it?
The downside is that getCookies() might have to block while waiting for
the mutex. But is that really a reason not to allow synchronous
(blocking) access to cookies? Given that the storage mutex is already
in the spec, doesn't it make sense to define a better synchronous API in
addition to the new asynchronous API?
David
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 8:23 PM, Peter Kasting wrote: > On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote: > >> I'm also less-than-thrilled with this being asynchronous, as I think the >> use cases for cookies are vastly differently than those for databases and >> web storage. The world is already parsing cookies synchronously right now, >> it doesn't seem like asynchronicity buys much benefit, it just introduces an >> additional level of indirection. > > > You haven't just spent several tortuous weeks trying to figure out how on > earth to correctly prompt for cookies in a multiprocess browser in a way > that doesn't break synchronicity requirements the way we have. > > Synchronous access to state didn't cause many issues when browsers were all > single-process, single-thread. That is increasingly not going to be the > world we live in. As Jonas mentioned, just look at localStorage (which, > contra your position, many developers have proposed using very much like > cookies) for recent history of why synchronous APIs are troublesome. > Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention. But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world. J
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote: > I'm also less-than-thrilled with this being asynchronous, as I think the > use cases for cookies are vastly differently than those for databases and > web storage. The world is already parsing cookies synchronously right now, > it doesn't seem like asynchronicity buys much benefit, it just introduces an > additional level of indirection. You haven't just spent several tortuous weeks trying to figure out how on earth to correctly prompt for cookies in a multiprocess browser in a way that doesn't break synchronicity requirements the way we have. Synchronous access to state didn't cause many issues when browsers were all single-process, single-thread. That is increasingly not going to be the world we live in. As Jonas mentioned, just look at localStorage (which, contra your position, many developers have proposed using very much like cookies) for recent history of why synchronous APIs are troublesome. PK
Re: [whatwg] HTML Cookie API
For reference, reading document.cookie has measurable performance cost in
Chromium since the cookie jar lives in a process separate from the process
running JavaScript. We could have minimized this cost by caching the
cookies locally, but then there are cache coherency issues.
I think the cookie APIs should have been asynchronous from the start.
Whenever an API is backed by I/O, asynchronous should be the rule.
-Darin
On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas wrote:
> I like the idea of creating an easier way to deal with cookies (which is
> why I wrote the YUI Cookie utility way back when). The thing that seems to
> be missing in your proposed API is what I consider to be the most common use
> case: retrieving the value of a single cookie. There's not many times when I
> need to get every single cookie that's available on the page, but there are
> plenty of times when I want to check the value of a single cookie. Using
> your API, getting the value of a single cookie with a known name becomes:
>
>document.getCookies(function(cookies) {
> for (var i=0; i < cookies.length; ++i){
> if(cookies[i].name == "my_cookie_name"){
> doSomething(cookies[i]);
> }
> }
>});
>
> That seems like a lot of work just to retrieve a single cookie value.
>
> I'm also less-than-thrilled with this being asynchronous, as I think the
> use cases for cookies are vastly differently than those for databases and
> web storage. The world is already parsing cookies synchronously right now,
> it doesn't seem like asynchronicity buys much benefit, it just introduces an
> additional level of indirection.
>
> -Nicholas
>
> __
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
> Morpheus: "My beliefs do not require them to."
>
> -Original Message-
> From: whatwg-boun...@lists.whatwg.org [mailto:
> whatwg-boun...@lists.whatwg.org] On Behalf Of Adam Barth
> Sent: Wednesday, February 24, 2010 8:47 AM
> To: Darin Fisher
> Cc: whatwg
> Subject: Re: [whatwg] HTML Cookie API
>
> Done.
>
> On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher wrote:
> > An explicit deleteCookie method might also be nice.
> > -Darin
> >
> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
> >>
> >> The document.cookie API is kind of terrible. Web developers shouldn't
> >> have to parse a cookie-string or prepare a properly formated
> >> set-cookie-string. Here's a proposal for an HTML cookie API that
> >> isn't as terrible:
> >>
> >>
> >>
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
> >>
> >> I'd like to propose we include this API in a future version of HTML.
> >> As always, feedback welcome.
> >>
> >> Adam
> >
> >
>
Re: [whatwg] HTML Cookie API
I like the idea of creating an easier way to deal with cookies (which is why I
wrote the YUI Cookie utility way back when). The thing that seems to be missing
in your proposed API is what I consider to be the most common use case:
retrieving the value of a single cookie. There's not many times when I need to
get every single cookie that's available on the page, but there are plenty of
times when I want to check the value of a single cookie. Using your API,
getting the value of a single cookie with a known name becomes:
document.getCookies(function(cookies) {
for (var i=0; i < cookies.length; ++i){
if(cookies[i].name == "my_cookie_name"){
doSomething(cookies[i]);
}
}
});
That seems like a lot of work just to retrieve a single cookie value.
I'm also less-than-thrilled with this being asynchronous, as I think the use
cases for cookies are vastly differently than those for databases and web
storage. The world is already parsing cookies synchronously right now, it
doesn't seem like asynchronicity buys much benefit, it just introduces an
additional level of indirection.
-Nicholas
__
Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Adam Barth
Sent: Wednesday, February 24, 2010 8:47 AM
To: Darin Fisher
Cc: whatwg
Subject: Re: [whatwg] HTML Cookie API
Done.
On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher wrote:
> An explicit deleteCookie method might also be nice.
> -Darin
>
> On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
>>
>> The document.cookie API is kind of terrible. Web developers shouldn't
>> have to parse a cookie-string or prepare a properly formated
>> set-cookie-string. Here's a proposal for an HTML cookie API that
>> isn't as terrible:
>>
>>
>> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>>
>> I'd like to propose we include this API in a future version of HTML.
>> As always, feedback welcome.
>>
>> Adam
>
>
Re: [whatwg] HTML Cookie API
Done. On Wed, Feb 24, 2010 at 12:29 AM, Darin Fisher wrote: > An explicit deleteCookie method might also be nice. > -Darin > > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >> >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. >> >> Adam > >
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 12:12 AM, Anne van Kesteren wrote: > On Wed, 24 Feb 2010 05:56:31 +0100, Adam Barth wrote: >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. > > On http-state you argue that we should replace the cookie protocol with > something else. Why would we want a better API for cookies then? We're going to be stuck with cookies for a long time. We might as well make the APIs for interacting with them not terrible. Independent of that, I think we should warn people who aren't yet stuck with cookies to avoid them. However, the prevailing opinion in that working group appears to be to remove that piece of advice. Adam
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 10:22 PM, Darin Fisher wrote:
> On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth wrote:
>> On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking wrote:
>> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
>> >> The document.cookie API is kind of terrible. Web developers shouldn't
>> >> have to parse a cookie-string or prepare a properly formated
>> >> set-cookie-string. Here's a proposal for an HTML cookie API that
>> >> isn't as terrible:
>> >>
>> >>
>> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
>> >>
>> >> I'd like to propose we include this API in a future version of HTML.
>> >> As always, feedback welcome.
>
> I have frequently seen code like this:
>
> document.cookie = "foo=1";
> if (document.cookie.indexOf("foo") == -1) return;
> document.cookie = "bar=2";
> if (document.cookie.indexOf("bar") == -1) return;
>
> I presume it is not uncommon for web authors to want to know if the cookies
> were set. Maybe there should be an optional error callback on
> document.setCookie?
Done.
Adam
Re: [whatwg] HTML Cookie API
An explicit deleteCookie method might also be nice. -Darin On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: > The document.cookie API is kind of terrible. Web developers shouldn't > have to parse a cookie-string or prepare a properly formated > set-cookie-string. Here's a proposal for an HTML cookie API that > isn't as terrible: > > > https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en > > I'd like to propose we include this API in a future version of HTML. > As always, feedback welcome. > > Adam >
Re: [whatwg] HTML Cookie API
On Wed, 24 Feb 2010 05:56:31 +0100, Adam Barth wrote: The document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. On http-state you argue that we should replace the cookie protocol with something else. Why would we want a better API for cookies then? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth wrote:
> On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking wrote:
> > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote:
> >> The document.cookie API is kind of terrible. Web developers shouldn't
> >> have to parse a cookie-string or prepare a properly formated
> >> set-cookie-string. Here's a proposal for an HTML cookie API that
> >> isn't as terrible:
> >>
> >>
> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en
> >>
> >> I'd like to propose we include this API in a future version of HTML.
> >> As always, feedback welcome.
> >
> > I really think the API should be asynchronous, as to avoid the mess
> > that .localStorage currently is.
>
> Done.
>
> Adam
>
I have frequently seen code like this:
document.cookie = "foo=1";
if (document.cookie.indexOf("foo") == -1) return;
document.cookie = "bar=2";
if (document.cookie.indexOf("bar") == -1) return;
I presume it is not uncommon for web authors to want to know if the cookies
were set. Maybe there should be an optional error callback on
document.setCookie?
-Darin
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth wrote: > On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking wrote: > > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: > >> The document.cookie API is kind of terrible. Web developers shouldn't > >> have to parse a cookie-string or prepare a properly formated > >> set-cookie-string. Here's a proposal for an HTML cookie API that > >> isn't as terrible: > >> > >> > https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en > >> > >> I'd like to propose we include this API in a future version of HTML. > >> As always, feedback welcome. > > > > I really think the API should be asynchronous, as to avoid the mess > > that .localStorage currently is. > > Done. > The "array-like object containing the Cookies for the document" should be a read-only copy of a set of objects that represent all the applicable cookies at some point between the request and the response. This needs to be really clear and it needs to be clear what happens if a user, say, calls setCookie() in the middle of iterating through the array-like object (imho the iteration should be unaffected). It's probably best to specify the ordering of Cookies in this array-like object to match rfc2965's ordering rules so that users of the API don't have to implement this ordering themselves. Accessing cookies from script is inherently racy - there is no way to promise that the browser will or will not return a cookie being set by some HTTP response arriving "at the same time" as the getCookies() call. There's nothing really you can do about this but I think that this fact should be highlighted in the spec. If a U-A's privacy settings disallow script from accessing cookies, there should be some clear behavior. It looks like a U-A could make setCookie() a no-op and always invoke the getCookies() callback with an empty list now - should that be specified? - James > Adam >
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking wrote: > On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: >> The document.cookie API is kind of terrible. Web developers shouldn't >> have to parse a cookie-string or prepare a properly formated >> set-cookie-string. Here's a proposal for an HTML cookie API that >> isn't as terrible: >> >> https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en >> >> I'd like to propose we include this API in a future version of HTML. >> As always, feedback welcome. > > I really think the API should be asynchronous, as to avoid the mess > that .localStorage currently is. Done. Adam
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth wrote: > The document.cookie API is kind of terrible. Web developers shouldn't > have to parse a cookie-string or prepare a properly formated > set-cookie-string. Here's a proposal for an HTML cookie API that > isn't as terrible: > > https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en > > I'd like to propose we include this API in a future version of HTML. > As always, feedback welcome. I really think the API should be asynchronous, as to avoid the mess that .localStorage currently is. / Jonas
[whatwg] HTML Cookie API
The document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMg&hl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. Adam
