[whatwg] localStorage, the storage mutex, document.domain, and workers
SUMMARY:
I haven't removed the storage mutex. I don't see any other workable
solution to the problem.
We can't change the API, as much as we'd like to, because it's already
shipped in IE, and it would simply be dumb for us to screw Microsoft over
here. It's hard enough to get them to implement specs without giving their
management more reasons for not being on the cutting edge.
We can't simply remove the storage mutex, because then we'll have race
conditions up the wazoo, especially for localStorage. We could probably
get away with letting document.cookie be unprotected, since IE has done
that for years and cookies aren't a high-traffic API, but who knows how
many bugs that's really causing. If implementations don't implement the
mutex around document.cookie access, I can't blame them, but it's a risk
that each implementor needs to evaluate on their own, the spec isn't going
to condone it.
I have made sure that as far as I am aware, there are no ways to
synchronously invoke script from another origin in HTML5 without dropping
the mutex (specifically, I've made history.back() and changing of
document.domain drop the mutex), and I've made it so that you can only
access localStorage objects of your effective script origin (i.e. changing
document.domain means your localStorage is no longer accessible). This
means that it should be possible to implement the storage mutex on a
per-domain basis. This should minimise the potential damage.
I haven't added localStorage to workers, because it'd be too easy to grab
the mutex and try to see if Pi is finite using a brute-force approach,
leaving all the other event loops that try to grab the mutex SOL.
I haven't added an async callback to localStorage yet, because I don't
imagine that most authors will use it given that they don't need to and
see no problems when testing (you'd only see issues if you tested having
two apps from the same domain both doing storage updates in long scripts).
LESSONS LEARNT
If we ever define a new API that needs a lock of some kind, the way to do
it is to use a callback, so that the UA can wait for the lock
asynchronously, and then run the callback once it has it. (This is what
the Web Database spec does, for instance.)
On Thu, 3 Sep 2009, timeless wrote:
On Sun, Aug 30, 2009 at 4:06 AM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
If getStorageUpdates() actually returned how *many* updates there were,
it could be a vaguely useful name.
If the answer is 0, then my application knows it doesn't need to try to
figure out how the world changed, right?
The answer 0 would only be useful if you were to grab the storage mutex
immediately upon receiving it, which defeats the point of the call.
On Fri, 4 Sep 2009, Jeremy Orlow wrote:
I like this idea except for one problem: It doesn't tell whether
something got changed without your knowledge. If you call alert, access
a plugin, etc it's possible to drop the lock. I think some sort of
global counter, variable, etc would be more valuable since it solves
both problems.
What's the use case for this? I don't understand what a script making use
of this would look like. (I mean, I can see how to write a demo that shows
using it, but how would a real site use it?)
On Fri, 4 Sep 2009, Chris Jones wrote:
I'd like to propose that HTML5 specify different schemes than a
conceptual global storage mutex to provide consistency guarantees for
localStorage and cookies.
Cookies would be protected according to Benjamin Smedberg's post in the
[whatwg] Storage mutex and cookies can lead to browser deadlock
thread. Roughly, this proposal would give scripts a consistent view of
document.cookie until they completed. AIUI this is stronger consistency
than Google Chrome provides today, and anecdotal evidence suggests even
their weaker consistency hasn't broken the web.
I think if we're willing to run the risk of pages stomping on each other,
we should just go ahead and not have locking at all, rather than trying to
show a consistent view that we know to be a lie.
That is, if this is going to fail when run in parallel:
var count = getCookie('counter');
counter += 1;
setCookie('data' + counter, data);
setCookie('counter', counter);
...then there's not much point worrying about whether the view is
consistent. Either way, data loss will occur.
localStorage would be changed in a non-backwards-compatible way.
I think this is a non-starter, as described above.
[transactions]
The problem with a system where transactions might fail based on timing is
that there's not much for the author to do but just try again, and that's
really not a good pattern to encourage. It's also likely that many authors
won't notice the failure case, leading to just another kind of race
condition very similar to what we're trying to avoid in the first place.
Re: [whatwg] article/section/details naming/definition problems
On Sep 16, 2009, at 17:27, Jeremy Keith wrote: Hixie outlined three reasons for having a separate article element: replacing div class=post so that you don't need to use classes for marking up blog posts enabling trivial conversion of html to atom for syndication and making it easier to navigate a page that has multiple articles when using accessibility tools The third use case is already solved with section. Do you accept the notion that ARIA should become syntactically obsolete over time so that its semantics are natively available in HTML proper? (See http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0031.html ) If yes, do you think role=article is a legitimate and useful feature in ARIA? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Feature requests in WebSocket
On Fri, 4 Sep 2009, Jeremy Orlow wrote: On Fri, Sep 4, 2009 at 2:37 PM, Ian Hickson i...@hixie.ch wrote: What would the wire level look like? It could be as simple as this: An extra byte or two at the beginning of every message that says which channel is transmitting. A way to send control messages, two of which would be used to open and close channels. I don't understand why we'd do that rather than just use two TCP connections. Latency and limits within the OS. I don't see how we could hit limits within the OS with Web Sockets. Latency could be a reason to have built-in multiplexing, but it's probably easier for the author to just do it manually, frankly. On Fri, Sep 4, 2009 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 14 Aug 2009, Jonas Sicking wrote: How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. The authors still have to implement it on the server side, though. You could have it be an optional feature. Like, the server could send back a flag saying oh by the way I support multiplexing? Yeah, I guess that could work. Might be a good way to extend the protocol to support this in the future -- a good forward migration path. The server would include a flag in the handshake, and the client would then know that it could send an 0x02 packet or something when it wanted to add a new connection... hm, that might be a little messy. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. That seems like a disaster waiting to happen -- it just takes one minor bug on the server for information to end up in the wrong channel. You could say the same thing about so many parts of the networking stack. Indeed, and I would hope we have learnt from those mistakes. On Fri, 4 Sep 2009, Jonas Sicking wrote: The authors still have to implement it on the server side, though. Experience from HTTP shows that there are much fewer HTTP server implementing the HTTP protocol, than there are authors using those servers. Experience also shows that HTTP is inanely complicated to implement. The lack of HTTP servers is a bug, not a feature. WebSockets is designed to be more like CGI than HTTP in terms of server-side complexity. Just like there are far more CGI implementations than HTTP implementations, I would expect -- and hope! -- that there will be far more Web Socket implementations than HTTP implementations. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. Do we really want two different pages sharing the same TCP connection? That seems like a disaster waiting to happen -- it just takes one minor bug on the server for information to end up in the wrong channel. That's what we do with HTTP today. So I would say yes. 4. If websocket is successful, websocket proxies will likely show up, allowing multiplexing across different users that share the same proxy. That sounds frightening. Again, HTTP benefits from this a lot today. HTTP is so complicated to implement that few have done so, and those who have are typically large teams over many years. Web Sockets is so simple to implement that you can literally do a fully compliant implementation in a few hours (it's about 100 lines of Perl). This is intentional, and good. But it means that we have to make sure we don't add features that can result in serious failures like the above. On Fri, 4 Sep 2009, Greg Wilkins wrote: The server on the server-side could hide the details from the server side developer. The server-side developer is the one writing the server. With HTTP, the server side developer handles requests and has little idea what connection they came over. This is not HTTP. I don't understand why we'd do that rather than just use two TCP connections. Because TCP connections are not free. Resources are often allocated server side per connection. As a server side developer, I would much rather have a little more parsing to do on fewer connections than less parsing on many more connections. Whether the resources to handle the connections are taken by the OS networking stack of the user-space WebSocket stack really doesn't change the need for resources. TCP/IP already supports all we need here. I don't see why we would want to reinvent this wheel inside a protocol tunneling through TCP. -- Ian Hickson U+1047E)\._.,--,'``.fL
Re: [whatwg] article/section/details naming/definition problems
Henri asked: do you think role=article is a legitimate and useful feature in ARIA? Pretty useful but not *as* useful as some of the biggies e.g. search, navigation, contentinfo, and all the roles to do with interaction. Do you accept the notion that ARIA should become syntactically obsolete over time so that its semantics are natively available in HTML proper? (See http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0031.html ) Now that's a big question. :-) If that is the one of the goals of HTML5 then aren't there going to be lots of existing role values that won't be covered by HTML? role=article would probably be the least of them. But, even accepting that ARIA roles should be obsoleted by HTML, that's not the same as being obsoleted by HTML *elements*. It's still possible to specify that a section is of a particular type (e.g. article) without necessarily creating a new element for it. Otherwise we'd have to create password, checkbox, radio elements, etc. instead of using input type=. So an answer of yes to your question doesn't mean that every current ARIA role needs a corresponding distinct element in HTML. Yes. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Note on 4.8.7 (video) and 4.8.8 (audio)
Ian Hickson i...@hixie.ch, 2009-09-14 06:52 +: The whole point is that this is _not_ fallback content of that nature. That's what the note was saying. Linking to that section would be flat-out wrong. Is there some other way in which I can clarify that the contents of the element are not fallback content as defined by the spec? The note for the video element reads: In particular, this content is not intended to address accessibility concerns. To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks) into their media streams. What would then be the recommended way to provide fallback content for a video like the following? http://upload.wikimedia.org/wikipedia/commons/2/23/Ara_chloroptera.ogg That's a 6-second video of a Red-and-green Macaw moving along a tree branch, with the only sounds being it making a brief vocalization, and some background sounds. It doesn't seem to lend itself either to fallback content provided by alternative media streams or by embedded captions or subtitles. --Mike -- Michael(tm) Smith http://people.w3.org/mike/
Re: [whatwg] article/section/details naming/definition problems
Erik Vorhes wrote: On Wed, Sep 16, 2009 at 3:35 AM, Bruce Lawsonbru...@opera.com wrote: there would also need to be acomment element I'd be *slightly* concerned that confusion could arise between a comment element and the!-- comment syntax --, at least in discussion. (I.e., what would HTML comment mean?) We couldn't use a comment element anyway for backwards compatibility reasons. IE does some weird stuff when parsing it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Note on 4.8.7 (video) and 4.8.8 (audio)
Michael(tm) Smith wrote: What would then be the recommended way to provide fallback content for a video like the following? http://upload.wikimedia.org/wikipedia/commons/2/23/Ara_chloroptera.ogg That's a 6-second video of a Red-and-green Macaw moving along a tree branch, with the only sounds being it making a brief vocalization, and some background sounds. It doesn't seem to lend itself either to fallback content provided by alternative media streams or by embedded captions or subtitles. That paragraph sounds like a reasonable alternative -- another argument for the text/html (or text/plain) source as a final alternative. On the other hand, I personally would prefer that sort of caption before deciding whether to watch in the first place, so maybe it could just be handled with an aria-describedby. -jJ
Re: [whatwg] localStorage, the storage mutex, document.domain, and workers
On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 15 Sep 2009, Jonas Sicking wrote: First off, I agree that not having localStorage in workers is a big problem that we need to address. If I were designing the localStorage interface today I would use the above interface that you suggest. Grabbing localStorage can only be done asynchronously, and while you're using it, no one else can get a reference to it. This way there are no race conditions, but also no way for anyone to have to lock. So one solution is to do that in parallel to the current localStorage interface. Let's say we introduce a 'clientStorage' object. You can only get a reference to it using a 'getClientStorage' function. This function is available both to workers and windows. The storage is separate from localStorage so no need to worry about the 'storage mutex'. I think we should be very careful before introducing a fourth storage mechanism to make sure that whatever we introduce really is something that's going to be very useful and really solve problems. I'd really rather not rush into adding yet another mechanism at this point. Sure. But what about the other idea Robert and Drew had (in the workers + local storage thread) about just having a WorkerLocalStorage mechanism? Only workers would be able to access it and the interface would be exactly the same as LocalStorage. The only difference is that the data is in a separate area (and pages/workers cannot share data). (Though we could, in the future, add such an async interface if we wanted to allow pages to access it.) I know the burden for implementation in WebKit is low, and I imagine (though don't know for sure) that the burden would be low in other browsers as well.
Re: [whatwg] localStorage, the storage mutex, document.domain, and workers
On Thu, Sep 17, 2009 at 10:53 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 15 Sep 2009, Jonas Sicking wrote: First off, I agree that not having localStorage in workers is a big problem that we need to address. If I were designing the localStorage interface today I would use the above interface that you suggest. Grabbing localStorage can only be done asynchronously, and while you're using it, no one else can get a reference to it. This way there are no race conditions, but also no way for anyone to have to lock. So one solution is to do that in parallel to the current localStorage interface. Let's say we introduce a 'clientStorage' object. You can only get a reference to it using a 'getClientStorage' function. This function is available both to workers and windows. The storage is separate from localStorage so no need to worry about the 'storage mutex'. I think we should be very careful before introducing a fourth storage mechanism to make sure that whatever we introduce really is something that's going to be very useful and really solve problems. I'd really rather not rush into adding yet another mechanism at this point. Sure. But what about the other idea Robert and Drew had (in the workers + local storage thread) about just having a WorkerLocalStorage mechanism? Only workers would be able to access it and the interface would be exactly the same as LocalStorage. The only difference is that the data is in a separate area (and pages/workers cannot share data). (Though we could, in the future, add such an async interface if we wanted to allow pages to access it.) I know the burden for implementation in WebKit is low, and I imagine (though don't know for sure) that the burden would be low in other browsers as well. This is what I think we should do. I do think that an async accessor in pages would increase its utility significantly. In fact, if we did that the interface could even work as an alternative to localStorage on the main thread for applications that worry about the locking, and thus unresponsive UI, that the storage mutex creates. / Jonas
Re: [whatwg] Spec comments, sections 4.9-4.10
On Mon, Sep 14, 2009 at 7:21 AM, Ian Hickson i...@hixie.ch wrote: I'm not really sure what you mean here. - There's the element's value content attribute. - There's the element's value DOM attribute. - There's the value mode that the value DOM attribute can be in. - There's the element's defaultValue DOM attribute (which reflects the element's value content attribute). - There's the element's actual value. - There's the value exposed to the user. Are you asking that the fifth of these (the value concept) should be renamed to something else? I'm not really sure, I just know I got confused by which value was being referred to in various cases. I'm not sure I can suggest any better wording, because I think I still don't understand what value is being referred to in a lot of cases. Which of the above is unclear? By this point I've totally forgotten how I was interpreting the text when I first read it, but I know I was confused. Ah. I think I'd rather stick to the explicit terms instead of adding more! Right, I didn't mean to suggest you should add more. Nothing is to be read between the lines -- unless it says that something can be changed, the default assumption is that it can't be changed. (There are a finite number of things that can be changed, and an infinite number that cannot, so it doesn't make sense to do it the other way around.) The wording Unless otherwise specified makes it sound like it's not otherwise specified, though, or at least it's noncommittal about whether it's otherwise specified. It would be clearer (and marginally shorter) if it said The user agent should not allow the user to modify the element's value or checkedness except as specified, thus making it clear that it *is* specified. The difference is stylistic. Compare the two in Safari. I think more informative notes about the purpose of things like this would make the spec a lot easier to comprehend. Added a note about this. Great. In 4.10.4.1.7: If the element is mutable, the user agent should allow the user to change the global date and time represented by its value, as obtained by parsing a global date and time from it. User agents must not allow the user to set the value to a string that is not a valid global date and time string expressed in UTC, though user agents may allow the user to set and view the time in another time zone and silently translate the time to and from the UTC time zone in the value. If the user agent provides a user interface for selecting a global date and time, then the value must be set to a valid global date and time string expressed in UTC representing the user's selection. User agents should allow the user to set the value to the empty string. This paragraph looks repetitive to me. I think the third sentence can just be dropped, unless I'm missing something -- does it add anything? This paragraph is setting out precisely what the requirements are for user agents. The four sentences each cover a slightly different aspect of the requirements. They don't seem to overlap at all -- the first says that the UI needs to allow changes, the second that if the user can set the value directly, the UA needs to prevent invalid values from being set, the third says that if the UA allows the user to set the value using some sort of UI, that the UI should convert the value to one of those valid things, and the fourth one says that in addition, the UA can allow the user to reset the value to nothing. As I'm reading it, the first two sentences imply the third. The user must be allowed to change it, but not to invalid values; so obviously any input mechanism that's provided must only allow valid values to be input. What incorrect behavior does the third sentence rule out, which the rest of the spec would permit? The third sentence isn't ruling out anything, it's requiring specifically that if the user agent offers a UI, say a clock, that the user agent set the value to a value that matches what the user selected, so that, for instance, setting the value to 4 o'clock when the user picked 2 o'clock would be non-conforming. Then the only significant part of the sentence is representing the user's selection, and a valid global date and time string expressed in UTC is in fact redundant to the second sentence? You could replace it with a date and time string or such, to make it clear that the sentence adds no additional requirement of validity beyond what the second sentence imposes. I really think it's self-evident that the user agent has to set the date and time to one corresponding to what the user actually selected, though. I know you like to be explicit, but . . . There are any number of possible ways of doing autocomplete that aren't necessarily worse than datalist, depending on what you want to do. Like what? readonly means that the value should be selectable for
[whatwg] Quoted (') and () appear as ('''') and (''''')
Printable Unicode characters are referred to in at least five different ways: U+003D EQUALS SIGN (code title==/code) U+003D EQUALS SIGN (code title==/code) U+003D EQUALS SIGN character (=) U+002D HYPHEN-MINUS (-) U+003D EQUALS SIGN Printable ASCII-characters are usually referred to as follows: 0x3D (ASCII '=') The ideal solution would of course be to make this fully consistent — e.g., by using the style U+... (code.../code) for Unicode all the time and perhaps also 0x... (ASCII code.../code) for ASCII. Failing that, ' and '' (two occurrences of each, excluding an unrelated unproblematic instance inside a script) should be changed since they appear confusingly as ' and in a sans-serif typeface. -- Øistein E. Andersen
Re: [whatwg] HTML 5 drag and drop feedback
As you stated, both IE and Safari have this thing pretty nailed down for quite a while now already. Both IE and Safari are quite buggy when it comes to drag-and-drop actually, at least compared to what the spec says (especially IE). Firefox has done a considerable amount of work to implement this as well and at the very least advertises it as a complete feature. Is there some way to measure the quality of implementations? We'll need a test suite. I started to summarize all the bugs and quirks of the browsers implementing these features but there are really too many in all browsers. It'd be easier to have a positive test suite to show what is actually working. You can search the bug reports for more info. No browser has implemented the copy/paste part of the spec. It's also noteworthy that the interaction with the OS, other applications and cross-window drag/drop is largely left up to the browser. So, even when everything works, the specifics of various implementations will vary. For example to override a link URI you want to set text/x-moz-url in Mozilla to get expected behavior of text/uri-list in other browsers. As for lazy data... If the drag/drop is actually a copy/paste, you still have to serialize ALL data. If your script made the assumption that it wouldn't, then that could cause some interesting bloated clipboard. To me, this is just another example of why the copy/paste API should be separate. I've also suggested that you allow for lazy loading of data as entire files using: dataTransfer.setRemoteData(type, uri); Using a remote URI in the clipboard, that API could lazily load data even after the document is unloaded. But I also like the idea of a callback. (Most annoying DnD bug right now: IE blocks the thread which means no setTimeout, no animations or anything asynchronous during a drag operation.)
Re: [whatwg] localStorage, the storage mutex, document.domain, and workers
On Thu, Sep 17, 2009 at 8:32 PM, Ian Hickson i...@hixie.ch wrote:
LESSONS LEARNT
If we ever define a new API that needs a lock of some kind, the way to do
it is to use a callback, so that the UA can wait for the lock
asynchronously, and then run the callback once it has it. (This is what
the Web Database spec does, for instance.)
When we add more of these features, I think we will need a way to acquire
multiple locks simultaneously before running a callback. (So if we had
localStorage.runTransaction(function(storage) { ... }) and
otherLockingThing.runTransaction(function(thing) { ... }), we could also
have, for example, window.runTransaction(localStorage, otherLockingThing,
function(storage, thing) { ... }).) So it may be worth thinking about what
that API should be and what we will need to add to each feature spec to
support it.
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
