Re: [whatwg] Comments on the definition of a valid e-mail address
Am Montag, den 24.08.2009, 16:33 -0400 schrieb Brian Campbell: Given that there are so many technically invalid addresses that actually do work to deliver mail, and that I'm sure some people have odd addresses due to poor form validation […] Well, maybe the RFC should be updated as well ? Or is this just normal accounting for the robustness principle ? Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Aug 26, 2009, at 22:54, Darin Fisher wrote: Firefox and IE implement window modal, which is clearly buggy, but of course the world hasn't imploded. FWIW, Firefox differs here on Windows and Mac. On Windows, you can close tabs in the window even when window.alert() is up, which may lead to interesting effects. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Web Storage: apparent contradiction in spec
Speaking up as an application developer ;-) here, I think the evict data at browser's choice route is fatal for new inventions in app development. I've been hoping that WebStorage and Offline together with other new APIs could provide a platform that allows us to build applications free from dependencies to specific platforms/OSs (a no-brainer for the web) and also freeing us from the tyranny of the 50-year old file concept (information doesn't necessarily want to be contained in files, and most of the time users don't want to do the additional task of administering file names and folder structures on a local disk). These new apps might not have a server at all, maybe using peer-to-peer technologies to exchange parts of its data with the outside world. If, like many say here, a user file is considered more precious than data in localStorage, and the latter may have an automatic eviction scheme, then these new apps cannot use WebStorage. Instead I would look forward to new File APIs, allowing me to store data in local files. And then we are back to having our users handling and managing files and folders on their local disk... To back up a bit, offline data can be used to improve applications in different ways, and here's a quick list of scenarios I come to think of: * the browser makes an automatic decision to cache certain server data * the application decides to cache certain server data without asking the user * the application caches certain server data in response to user command (I need to have all my mail for offline access while I'm on the plane) * the application allows creation of new data and modification of existing cached server data while offline * the application allows creation and modification of data without relying on that there is a server or a copy of the data on that server If localStorage data is not considered precious I can only see the first two types of caching possible in professional applications. Even the third point would not be acceptable if the user has specifically asked to have a certain subset of his data available while travelling the Amazonas, just to discover that it was evicted because the browser decided to. As someone said, I think it is important that the spec clarifies which of these scenarios WebStorage is aiming to fulfill. Best regards Mike Wilson Drew Wilson wrote: This is one of those times when I *really* wish that the application developer community was more active on this list. I absolutely understand Linus' point of view, but I also feel like we are really hamstringing applications when we make choices like this and I wish that those developers were more vocally represented in these types of discussions. Going down this path would basically kill the ability to have offline web applications, because there would be no guarantees that the data would persist until the user comes back online. But since that point's already been made several times, I guess it's not a compelling argument. -atw On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson li...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I also want to avoid any [Yes] [No] dialogs. Can I do something scary [Yes] [No]? Can I do something innocuous [Yes] [No]? Users shouldn't be forced to make those kinds of safety judgements. I'm guilty of instigating at least one of those dialogs. As shamed politicians do I'll retreat to the passive voice: Mistakes were made. I'm not opposed to web apps manipulating files on the user's computer, but the user should be in explicit control. I'd support input type=open and input type=save that worked similarly to input type=file. User agents are already registering for file types so that double clicking a file with a certain extension can be automatically sent to an URL, perhaps residing in an AppCache. In addition, I'd like to see the pop-up dialogs for the location API removed. I find the Can I know where you are? dialogs on the iPhone very annoying. Mistakes were made. Perhaps we can find a way to make input type=location work well instead. Linus On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps to
Re: [whatwg] Web Storage: apparent contradiction in spec
On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote: To repeat what I said up above: Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't. That makes sense to me. There might even be more than two categories: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. Regards, Maciej
Re: [whatwg] Web Storage: apparent contradiction in spec
On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. The only catch being that if the web app decides this for itself, a malicious script or tracking cookie will be marked as critical user data when in fact the user would disagree. On the plus side, it would mean a browser could default to not allowing storage in the critical user data by default and then let users whitelist just the sites they want. This could be through an evil dialog, or just a less intrusive indicator somewhere the website itself would be able to detect that it couldn¹t save and warn the user in whatever way is most appropriate. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 628 200 182 x481 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Web Storage: apparent contradiction in spec
Adrian Sutton said: On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. The only catch being that if the web app decides this for itself, a malicious script or tracking cookie will be marked as critical user data when in fact the user would disagree. On the plus side, it would mean a browser could default to not allowing storage in the critical user data by default and then let users whitelist just the sites they want. This could be through an evil dialog, or just a less intrusive indicator somewhere - the website itself would be able to detect that it couldn't save and warn the user in whatever way is most appropriate. This seems to me a better idea than having multiple storage areas (SessionStorage, CachedStorage and FileStorage as suggested by Brady). However this could lead to even more evil dialogs: Do you want to save this data? Is it important? How important is it? The user - and for that matter, the app or UA - doesn't necessarily know how critical a piece of data is. The user doesn't know because without some form of notification they won't know what the lifetime of that data is (and even if they do they will have to know how that lifetime impacts on app functionality). The UA doesn't know because it doesn't understand the nature of the data without the user telling it. The app doesn't necessarily know because it can't see the wider implications of saving the data - storage space on the machine etc. Catch 22. So, to what extent do people think that automatic decisions could be made by the UA and app regarding the criticality of a particular piece of data? The more the saving of data can be automated - with the right level of importance attached to it - the better, saving obtrusive and potentially confusing dialogs, and (hopefully) saving the right data in the right way. Perhaps UAs could notify apps of the storage space available and user preferences on the saving of data up front, helping the app and UA to make reasonable decisions, only asking for user confirmation where an reasonable automatic decision can't be made. It's a head-twister, this one. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com
Re: [whatwg] Web Storage: apparent contradiction in spec
I'm one of the lurking web application developers. This discussion has gone mostly how I was hoping, but since 'offline apps' has come up again, I might bootstrap that a bit. Below are some use cases, but I'll summarize my perspective briefly. 1. To run Doom requiring 500M of localStorage sounds like an 'application'--both users and developers currently have the expectation that users have to approve something like that before being installed to their computers to consume possibly valuable resources. A preliminary prompt to the user sounds reasonable and expected here. 2. Once, I've approved of an application to store data locally, that data could very easily be incredibly precious to both user and developer. Neither would want that data to be swept away by a garbage-collecting browser without user/developer action. 3. If the developer is presented with an unprompted option to store data permanently or just have it 'cached'--I'm not sure why the developer (both the nefarious and the good) would ever opt for the only-cached version. 4. We'd like either (OffTopic) a. localStorage to work for file:// AND/OR b. there to be some way for someone with file access to change the manifest file cache in offline applications (while preserving SOME USE CASES -- Where I work (http://ccnmtl.columbia.edu), we have two main use cases for offline applications, which would be great if they were accomodated in the spec and even more importantly, browsers :-) 1. Static deployment as an 'offline app' http://ccnmtl.columbia.edu/portfolio/medicine_and_health/masivukeni.html Requirements/Constraints: * We were most familiar with programming and deploying web applications, so we preferred to use html/js (and python for backend to content development) * The application was to be run on a laptop which could not (and should not) connect to the Internet while being used. * Data (including user accounts) is then maintained using localStorage. * Rare updates (for critical bugs, e.g.) would not require online access again. Experience/Lessons: * We deployed this with Firefox's legacy globalStorage (before ffox3.5 came out) and static html files accessed at file:// * As written, it no longer works in ffox 3.5 or even with updates to ffox 3.0, because whereas file://localhost/ once worked (and thus globalStorage['localhost']), but seems to have been removed. Thankfully, as deployed, it's not connected to the Internet to receive updates :-) * If we implemented it again (which we will!) for HTML5, we would have the laptop download the files as an offline app with a manifest. Then localStorage would (hopefully) still work, and work upon visiting the domain--even offline. However, this might cause problems in updating the cached files without bringing the computer back online. 2. Deprecating experience for unprivileged users. * We have some services which allow annotation of primary sources (video/audio/images). * Some of these sites have public content, but we do not have the resources or interest in storing annotation/analysis from other users. Nonetheless, we've considered offline storage as a way to allow non-privileged users to analyze the content and store their data locally--to be saved for their own benefit and possibly later to be uploaded or shared elsewhere. In concluding, many thanks to all those that are working on HTML5 (esp. the browser vendors). It's an exciting time to be a web developer. cheers, Schuyler Message: 1 Date: Wed, 26 Aug 2009 20:54:12 -0700 From: Drew Wilson atwil...@google.com To: Linus Upson li...@google.com Cc: Brady Eidson beid...@apple.com, WHATWG List wha...@whatwg.org, Jeremy Orlow jor...@chromium.org, Jens Alfke s...@google.com, Aaron Boodman a...@google.com Subject: Re: [whatwg] Web Storage: apparent contradiction in spec Message-ID: f965ae410908262054y7d405cbdq2f7b115c7b694...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 This is one of those times when I *really* wish that the application developer community was more active on this list. I absolutely understand Linus' point of view, but I also feel like we are really hamstringing applications when we make choices like this and I wish that those developers were more vocally represented in these types of discussions. Going down this path would basically kill the ability to have offline web applications, because there would be no guarantees that the data would persist until the user comes back online. But since that point's already been made several times, I guess it's not a compelling argument. -atw On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson li...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog
Re: [whatwg] Web Storage: apparent contradiction in spec
Adrian Sutton wrote: On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. The only catch being that if the web app decides this for itself, a malicious script or tracking cookie will be marked as critical user data when in fact the user would disagree. On the plus side, it would mean a browser could default to not allowing storage in the critical user data by default and then let users whitelist just the sites they want. This could be through an evil dialog, or just a less intrusive indicator somewhere the website itself would be able to detect that it couldn¹t save and warn the user in whatever way is most appropriate. I don't fancy having to explain to my Mum that she has to go through some complex (to her) sequence of operations to see if a site is storing her important data somewhere where it might be deleted or in some secure area. Nor do I fancy explaining the procedure for changing between one and the other. I don't really see how the site could help either. I guess it might be possible for it to put up a your data is stored in a non-persistent way message, but instructions to change to persistent storage would have to be per-browser and possibly per browser version; no good for the people who don't know the difference between the browser, the internet and google. I can't imagine how to make this simple enough for end users without all data being persistent by default. Even then, knowing how to clear out data once the quota is hit is likely to be difficult and confusing.
Re: [whatwg] Web Storage: apparent contradiction in spec
And to confound the problem further, UAs dont have meta-data on hand with which to relate various pieces of local data together and attribute them to a specific user-identifiable 'application'. Everything is bound to a security-origin, but that doesn't clearly identify or label an 'application'. On Thu, Aug 27, 2009 at 8:10 AM, Chris Taylor chris.tay...@figureout.comwrote: Adrian Sutton said: On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. The only catch being that if the web app decides this for itself, a malicious script or tracking cookie will be marked as critical user data when in fact the user would disagree. On the plus side, it would mean a browser could default to not allowing storage in the critical user data by default and then let users whitelist just the sites they want. This could be through an evil dialog, or just a less intrusive indicator somewhere - the website itself would be able to detect that it couldn't save and warn the user in whatever way is most appropriate. This seems to me a better idea than having multiple storage areas (SessionStorage, CachedStorage and FileStorage as suggested by Brady). However this could lead to even more evil dialogs: Do you want to save this data? Is it important? How important is it? The user - and for that matter, the app or UA - doesn't necessarily know how critical a piece of data is. The user doesn't know because without some form of notification they won't know what the lifetime of that data is (and even if they do they will have to know how that lifetime impacts on app functionality). The UA doesn't know because it doesn't understand the nature of the data without the user telling it. The app doesn't necessarily know because it can't see the wider implications of saving the data - storage space on the machine etc. Catch 22. So, to what extent do people think that automatic decisions could be made by the UA and app regarding the criticality of a particular piece of data? The more the saving of data can be automated - with the right level of importance attached to it - the better, saving obtrusive and potentially confusing dialogs, and (hopefully) saving the right data in the right way. Perhaps UAs could notify apps of the storage space available and user preferences on the saving of data up front, helping the app and UA to make reasonable decisions, only asking for user confirmation where an reasonable automatic decision can't be made. It's a head-twister, this one. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Aug 27, 2009 at 10:47 AM, Maciej Stachowiakm...@apple.com wrote: That makes sense to me. There might even be more than two categories: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. I don't see the utility in this level of granularity. Two levels seem fine: delete at will as long as the app isn't actually running, and never delete once stored without explicit user action. On Thu, Aug 27, 2009 at 10:52 AM, Adrian Suttonadrian.sut...@ephox.com wrote: The only catch being that if the web app decides this for itself, a malicious script or tracking cookie will be marked as critical user data when in fact the user would disagree. Dispose when you feel like it storage doesn't provide any better protection for the user -- the site can always reset it regularly when the user visits. Cookies are already widely used for tracking, and work fine. Flash localStorage is used for tracking mainly because users don't know how to clear it, I suspect, not because it's more persistent than cookies in practice. (One of the many reasons HTML 5 needs to kill Flash.) On Thu, Aug 27, 2009 at 11:10 AM, Chris Taylorchris.tay...@figureout.com wrote: This seems to me a better idea than having multiple storage areas (SessionStorage, CachedStorage and FileStorage as suggested by Brady). However this could lead to even more evil dialogs: Do you want to save this data? Is it important? How important is it? The user - and for that matter, the app or UA - doesn't necessarily know how critical a piece of data is. The decision needs to be made by the app. The app knows whether it's just doing caching, or needs persistence. The UA doesn't know, and nor does the user. I expect that as with cookies, the default in most browsers would be to let the app decide how long it wants to store the data with no user interaction, but privacy-aware users would be able to get more control. I also think it's clear that localStorage would not persist after things like exiting privacy mode, or logging out of a public terminal (if correctly configured), or clicking a clear private data button (if that also cleared bookmarks/history/etc.). Nobody's saying store forever, just don't delete except by explicit user request. So, to what extent do people think that automatic decisions could be made by the UA and app regarding the criticality of a particular piece of data? I think criticality is the wrong word to use. Persistence is better. Persistent data may be unimportant, and transient data may be critical.
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Aug 27, 2009 at 11:14 AM, Schuyler Duveenwha...@graffitiweb.org wrote: 1. To run Doom requiring 500M of localStorage sounds like an 'application'--both users and developers currently have the expectation that users have to approve something like that before being installed to their computers to consume possibly valuable resources. A preliminary prompt to the user sounds reasonable and expected here. I expect 500 MB will require a prompt by anyone's standards, yes, unless maybe the user has a terabyte of free disk space. 3. If the developer is presented with an unprompted option to store data permanently or just have it 'cached'--I'm not sure why the developer (both the nefarious and the good) would ever opt for the only-cached version. For the same reason developers write files in /tmp. In concluding, many thanks to all those that are working on HTML5 (esp. the browser vendors). It's an exciting time to be a web developer. Indeed!
Re: [whatwg] Web Storage: apparent contradiction in spec
Aryeh Gregor wrote: On Thu, Aug 27, 2009 at 11:14 AM, Schuyler Duveenwha...@graffitiweb.org wrote: 1. To run Doom requiring 500M of localStorage sounds like an 'application'--both users and developers currently have the expectation that users have to approve something like that before being installed to their computers to consume possibly valuable resources. A preliminary prompt to the user sounds reasonable and expected here. I expect 500 MB will require a prompt by anyone's standards, yes, unless maybe the user has a terabyte of free disk space. 3. If the developer is presented with an unprompted option to store data permanently or just have it 'cached'--I'm not sure why the developer (both the nefarious and the good) would ever opt for the only-cached version. For the same reason developers write files in /tmp. If it's user-specific, then why not just use sessionStorage? If it's non-user specific (e.g. defaults) or cachable user-data, why not have it cached with normal HTTP as a file, with an XHR (with allow caching headers)? cheers, Schuyler In concluding, many thanks to all those that are working on HTML5 (esp. the browser vendors). It's an exciting time to be a web developer. Indeed!
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Aug 27, 2009 at 11:53 AM, Schuyler Duveenwha...@graffitiweb.org wrote: If it's user-specific, then why not just use sessionStorage? Hmm. You're right, there's a lot of overlap there. sessionStorage might be sufficient for caching, for most applications. If not, localStorage could be used and managed manually. I retract my opinion on the usefulness of two different types of localStorage; I'll defer to the developers of actual web apps here.
Re: [whatwg] Web Storage: apparent contradiction in spec
On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote: On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote: To repeat what I said up above: Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't. That makes sense to me. There might even be more than two categories: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. I agree with Maciej's 4-level distinction on philosophical grounds, and think it's a fine list of use cases. But I think there's been a reasonable amount of agreement on this list that it is unnecessarily fine grained. A developer who is consciously choosing a cache will always choose the most aggressive cache, and a developer who is consciously choose file storage will always choose the most sacred file storage. So we're left with the cache vs file distinction once more. All browser vendors who have implemented LocalStorage are willing to implement the cache, because what they've done either meets or exceeds the cache use-case. The remaining question is the file storage. How do we implement this distinction? I don't like the idea of having different modes on LocalStorage. How would the different mode be triggered? How would it be managed? What happens when two applications from the same security origin try to mix modes? Different modes just makes what is already a dirt simple API more complex, makes implementation more difficult for browser vendors, and confuses web developers. So I resubmit my three-Storage-object solution: SessionStorage, CacheStorage, and FileStorage. From this discussion, it appears that FileStorage is something Google might not be willing to implement. That's fine! They can have the object available to scripts but just give it a zero quota. To be more friendly to developers and not force them into checking abilities by catching exceptions we could add one more property to the storage interface so they can check ahead of time whether their attempt to store data will fail. Web developers would then have the ability to make the conscious decision of Is a cache good enough? and fallback to CacheStorage, or decide No, I really need persistent data and fallback to Flash or some other plug-in. The interfaces are all so similar as to be pretty painless for the developer. Thoughts? ~Brady
[whatwg] Proposal for local-storage file management
[This is a spin-off of Web Storage: apparent contradiction in spec. I'm starting a new thread to make a specific proposal.] I agree that where possible we should find a way to do things without adding Mother-may-I dialog boxes. But I also believe we need some user interaction to enable a site to store nontrivial amounts of permanent local data, to avoid Linus's griefer scenario. Conundrum. But maybe the user interaction can be made to fit into existing familiar workflows. In a traditional document-based UI, the app prompts the user with a standard Save dialog box when it needs to create a new data storage area (a file). A default name and location are filled in, but the user can customize, or of course hit Cancel. Why not re-use that same model for HTML5 local storage? After all, we know the data is going to end up in the filesystem, so why not let the user pick where to put it? This way every web-app gets a separate local file. Internally it's probably a sqlite database or DBM file or whatever, but that's unimportant. The user follows the age-old save-a- file workflow to create one, so s/he is in control of whether it's created and where it goes. It gets backed up along with the user's other data. The user can trash it later on to make room or for privacy purposes. Here's what a typical scenario might look like: Ellen tells me about a great online animation program. I go to its site, and it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching frames of an animation. (Behind the scenes, the app is storing my drawings in session storage. This is considered temporary, so the browser gives it a reasonable quota without any user interaction.) After a while I decide I want to keep using the app, and the stuff I've drawn has potential, so I decide to save it to disk. I click the Save button, and the site (actually the browser) puts up a standard Save dialog box. (Behind the scenes the JS code is writing a value to persistent local storage, and since no storage exists yet for its domain, the browser is prompting the user.) The dialog's prompt is something like Save SooperAnimator.com data as:, and the initial destination is ~/Documents/Web Documents/ SooperAnimator.com Data. I hit Enter and my animation is saved. (Behind the scenes the browser created a new local-storage file at that location, and remembered where it put it.) Next month I remember that animation in progress and go back to the site. My work appears just the way I left it. (The site's script accessed its persistent storage, so the browser looked up where it put the file and opened it.) I do some more work on it; this time as I save (or maybe it auto-saves) the data gets written to the storage file without any more interaction because the file already exists. Next year I've switched allegiance to UltraAnimate.com, so while cleaning house I go through my Web Documents folder, see the old SooperAnimator.com Data file, and trash it to save disk space. This seems to end up as a combination of the local storage API with some of the behavior of the filesystem access proposal (which to be honest I haven't read yet.) In essence the entire local storage object space is implemented as a key-value DB file. Does this seem reasonable? —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
I don't think there is consensus at Google yet. I'm not saying that UAs shouldn't provide file-like lifetime semantics for storage. I'm just saying the user should decide, not the web page. Here's one way such a thing could be achieved: input type=storage src=button.png quota=20GB / When the user clicks the button they see a dialog that mail.google.com would like to use 20GB of storage. You have 50GB of free space. [Yes] [No]. Script can't cause the dialog to appear, only a user action. There would also be some affordance in that dialog to allow the user to manage persistent storage from other domains. A small Other sites are using 2GB of storage link perhaps. AppCache, LocalStrorage, and all other persistent bits for that domain would live within this quota. UAs would take this user action as a strong signal that the data is valuable and would act accordingly. If web sites use LocalStorage, AppCache, et. al. without the user clicking on and accepting a storage input button, then the UA would be free to garbage collect as it sees fit. Good UAs would do a good job of not throwing away things that are important to the user, just as they do today with cookies. Linus On Thu, Aug 27, 2009 at 9:42 AM, Brady Eidson beid...@apple.com wrote: On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote: On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote: To repeat what I said up above: *Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't.* That makes sense to me. There might even be more than two categories: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. I agree with Maciej's 4-level distinction on philosophical grounds, and think it's a fine list of use cases. But I think there's been a reasonable amount of agreement on this list that it is unnecessarily fine grained. A developer who is consciously choosing a cache will always choose the most aggressive cache, and a developer who is consciously choose file storage will always choose the most sacred file storage. So we're left with the cache vs file distinction once more. All browser vendors who have implemented LocalStorage are willing to implement the cache, because what they've done either meets or exceeds the cache use-case. The remaining question is the file storage. How do we implement this distinction? I don't like the idea of having different modes on LocalStorage. How would the different mode be triggered? How would it be managed? What happens when two applications from the same security origin try to mix modes? Different modes just makes what is already a dirt simple API more complex, makes implementation more difficult for browser vendors, and confuses web developers. So I resubmit my three-Storage-object solution: SessionStorage, CacheStorage, and FileStorage. From this discussion, it appears that FileStorage is something Google might not be willing to implement. That's fine! They can have the object available to scripts but just give it a zero quota. To be more friendly to developers and not force them into checking abilities by catching exceptions we could add one more property to the storage interface so they can check ahead of time whether their attempt to store data will fail. Web developers would then have the ability to make the conscious decision of Is a cache good enough? and fallback to CacheStorage, or decide No, I really need persistent data and fallback to Flash or some other plug-in. The interfaces are all so similar as to be pretty painless for the developer. Thoughts? ~Brady
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 8:23 PM, Linus Upsonli...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I see what you're saying. If the web is able to use local storage and UAs aren't allowed to prune it, then the storage used by web browsers tends to grow forever. If you want the web to continue to be completely stateless, there is no way around this. On Thu, Aug 27, 2009 at 10:18 AM, Erik Kayerik...@google.com wrote: I also think this thread is jumping to hyperbole about how the UA would be deleting data arbitrarily. Reasonable cache eviction algorithms won't cause much of a problem here. Do you use offline email all of the time? Guess what? It won't be evicted. Did you recently make change to an offline document that you didn't sync? It won't be evicted. The things that are problematic are the things which are accessed infrequently yet only exist in this local storage. See my argument above for why I think local storage isn't a great solution to offline only data anyway. I agree you could get 95% of the way there. But I can prove that this problem will happen in the real world. All I have to do is have a user with a small enough disk (an iPhone) and enough applications storing precious data. No amount of heuristics will stop the UA from either accidentally deleting something the user wanted, or asking the user to choose something to delete in this case. On Thu, Aug 27, 2009 at 10:18 AM, Erik Kayerik...@google.com wrote: What kinds of applications do people write against non-prompted Flash storage? As far as I can tell, it's used as a way to store cookies that are less likely to be deleted. It's not for data that the user would define as precious. How do I get data out of Flash storage? How do I back it up? Nobody does because they don't care and there isn't a use case driving this need today. The data isn't precious. Sure, but we're only having this conversation at all because we believe that the existing technology isn't meeting some use cases. People want to build offline applications based on web technology, and those apps tend to want to store data persistently and have it be treated as precious. If you accept this use case exists, and you accept that it is not possible for a UA to automatically make this decision, then we're just left with how to get the user involved. I think we are seeing, again, that there needs to be a difference between installed apps built on the web platform and the web as it is today. The web we know and love is stateless and should stay that way. Installed apps have state, and have to be actively managed by users. In that world, I think that the spec should be silent on what promises the UA makes wrt the data. It will be client-type-dependent. - a
Re: [whatwg] Proposal for local-storage file management
I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian 2009/8/27 Jens Alfke s...@google.com [This is a spin-off of Web Storage: apparent contradiction in spec. I'm starting a new thread to make a specific proposal.] I agree that where possible we should find a way to do things without adding Mother-may-I dialog boxes. But I also believe we need some user interaction to enable a site to store nontrivial amounts of permanent local data, to avoid Linus's griefer scenario. Conundrum. But maybe the user interaction can be made to fit into existing familiar workflows. In a traditional document-based UI, the app prompts the user with a standard Save dialog box when it needs to create a new data storage area (a file). A default name and location are filled in, but the user can customize, or of course hit Cancel. Why not re-use that same model for HTML5 local storage? After all, we know the data is going to end up in the filesystem, so why not let the user pick where to put it? This way every web-app gets a separate local file. Internally it's probably a sqlite database or DBM file or whatever, but that's unimportant. The user follows the age-old save-a-file workflow to create one, so s/he is in control of whether it's created and where it goes. It gets backed up along with the user's other data. The user can trash it later on to make room or for privacy purposes. Here's what a typical scenario might look like: Ellen tells me about a great online animation program. I go to its site, and it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching frames of an animation. (Behind the scenes, the app is storing my drawings in session storage. This is considered temporary, so the browser gives it a reasonable quota without any user interaction.) After a while I decide I want to keep using the app, and the stuff I've drawn has potential, so I decide to save it to disk. I click the Save button, and the site (actually the browser) puts up a standard Save dialog box. (Behind the scenes the JS code is writing a value to persistent local storage, and since no storage exists yet for its domain, the browser is prompting the user.) The dialog's prompt is something like Save SooperAnimator.com data as:, and the initial destination is ~/Documents/Web Documents/SooperAnimator.com Data. I hit Enter and my animation is saved. (Behind the scenes the browser created a new local-storage file at that location, and remembered where it put it.) Next month I remember that animation in progress and go back to the site. My work appears just the way I left it. (The site's script accessed its persistent storage, so the browser looked up where it put the file and opened it.) I do some more work on it; this time as I save (or maybe it auto-saves) the data gets written to the storage file without any more interaction because the file already exists. Next year I've switched allegiance to UltraAnimate.com, so while cleaning house I go through my Web Documents folder, see the old SooperAnimator.com Data file, and trash it to save disk space. This seems to end up as a combination of the local storage API with some of the behavior of the filesystem access proposal (which to be honest I haven't read yet.) In essence the entire local storage object space is implemented as a key-value DB file. Does this seem reasonable? —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
There should also be a way to ask for more quota (from the user) without losing user data. The API via a form element is a little odd--generally forms are for submitting information to the site. Historically, all of these kinds of things are done via javascript: * cookies * opensearch additions * extension additions This would also have the benefit of allowing a Worker() to request quota without something on the page. cheers, Schuyler Linus Upson wrote: I don't think there is consensus at Google yet. I'm not saying that UAs shouldn't provide file-like lifetime semantics for storage. I'm just saying the user should decide, not the web page. Here's one way such a thing could be achieved: input type=storage src=button.png quota=20GB / When the user clicks the button they see a dialog that mail.google.com http://mail.google.com would like to use 20GB of storage. You have 50GB of free space. [Yes] [No]. Script can't cause the dialog to appear, only a user action. There would also be some affordance in that dialog to allow the user to manage persistent storage from other domains. A small Other sites are using 2GB of storage link perhaps. AppCache, LocalStrorage, and all other persistent bits for that domain would live within this quota. UAs would take this user action as a strong signal that the data is valuable and would act accordingly. If web sites use LocalStorage, AppCache, et. al. without the user clicking on and accepting a storage input button, then the UA would be free to garbage collect as it sees fit. Good UAs would do a good job of not throwing away things that are important to the user, just as they do today with cookies. Linus On Thu, Aug 27, 2009 at 9:42 AM, Brady Eidson beid...@apple.com mailto:beid...@apple.com wrote: On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote: On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote: To repeat what I said up above: *Maybe the local storage API needs a way to distinguish between cached data that can be silently thrown away, and important data that can't.* That makes sense to me. There might even be more than two categories: - Cached for convenience - discarding this will affect performance but not functionality. - Useful for offline use - discarding this will prevent some data from being accessed when offline. - Critical for offline use - discarding this will prevent the app storing this data from working offline at all. - Critical user data - discarding this will lead to permanent user data loss. I agree with Maciej's 4-level distinction on philosophical grounds, and think it's a fine list of use cases. But I think there's been a reasonable amount of agreement on this list that it is unnecessarily fine grained. A developer who is consciously choosing a cache will always choose the most aggressive cache, and a developer who is consciously choose file storage will always choose the most sacred file storage. So we're left with the cache vs file distinction once more. All browser vendors who have implemented LocalStorage are willing to implement the cache, because what they've done either meets or exceeds the cache use-case. The remaining question is the file storage. How do we implement this distinction? I don't like the idea of having different modes on LocalStorage. How would the different mode be triggered? How would it be managed? What happens when two applications from the same security origin try to mix modes? Different modes just makes what is already a dirt simple API more complex, makes implementation more difficult for browser vendors, and confuses web developers. So I resubmit my three-Storage-object solution: SessionStorage, CacheStorage, and FileStorage. From this discussion, it appears that FileStorage is something Google might not be willing to implement. That's fine! They can have the object available to scripts but just give it a zero quota. To be more friendly to developers and not force them into checking abilities by catching exceptions we could add one more property to the storage interface so they can check ahead of time whether their attempt to store data will fail. Web developers would then have the ability to make the conscious decision of Is a cache good enough? and fallback to CacheStorage, or decide No, I really need persistent data and fallback to Flash or some other plug-in. The interfaces are all so similar as to be pretty painless for the developer. Thoughts? ~Brady
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 8:23 PM, Linus Upsonli...@google.com wrote: The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. While that is certainly one of the outcomes, and I agree a bad one, I am not sure that the user experience needs to be that bleak. Further, I expect that most UAs will need some dialog like this to let users manage the data in some cases anyway -- if users can grant permissions, they'll need to be able to revoke them, etc. I think that there is a lot of data that UAs can use to present likely targets for the user, as infrequently used desktop icons or similar endeavour to do. Bookmarked sites would be advantaged, as would sites that have had their stored data read recently (or have an active cookie, history frequency data, etc.). I think highly of myself and my team, to be sure, but I don't think that we are really going to always know better than the user -- even a technically naive user -- what they consider to be important data. Mike
Re: [whatwg] Proposal for local-storage file management
I like this proposal. It was what I had in mind with input type=open and input type=save. The only small change I'd make is that the page can only maintain a reference to the file for the life of that page. After that, the user needs to click open again. The open and save dialogs may remember recent files to make it easy for the user. Linus 2009/8/27 Jens Alfke s...@google.com [This is a spin-off of Web Storage: apparent contradiction in spec. I'm starting a new thread to make a specific proposal.] I agree that where possible we should find a way to do things without adding Mother-may-I dialog boxes. But I also believe we need some user interaction to enable a site to store nontrivial amounts of permanent local data, to avoid Linus's griefer scenario. Conundrum. But maybe the user interaction can be made to fit into existing familiar workflows. In a traditional document-based UI, the app prompts the user with a standard Save dialog box when it needs to create a new data storage area (a file). A default name and location are filled in, but the user can customize, or of course hit Cancel. Why not re-use that same model for HTML5 local storage? After all, we know the data is going to end up in the filesystem, so why not let the user pick where to put it? This way every web-app gets a separate local file. Internally it's probably a sqlite database or DBM file or whatever, but that's unimportant. The user follows the age-old save-a-file workflow to create one, so s/he is in control of whether it's created and where it goes. It gets backed up along with the user's other data. The user can trash it later on to make room or for privacy purposes. Here's what a typical scenario might look like: Ellen tells me about a great online animation program. I go to its site, and it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching frames of an animation. (Behind the scenes, the app is storing my drawings in session storage. This is considered temporary, so the browser gives it a reasonable quota without any user interaction.) After a while I decide I want to keep using the app, and the stuff I've drawn has potential, so I decide to save it to disk. I click the Save button, and the site (actually the browser) puts up a standard Save dialog box. (Behind the scenes the JS code is writing a value to persistent local storage, and since no storage exists yet for its domain, the browser is prompting the user.) The dialog's prompt is something like Save SooperAnimator.com data as:, and the initial destination is ~/Documents/Web Documents/SooperAnimator.com Data. I hit Enter and my animation is saved. (Behind the scenes the browser created a new local-storage file at that location, and remembered where it put it.) Next month I remember that animation in progress and go back to the site. My work appears just the way I left it. (The site's script accessed its persistent storage, so the browser looked up where it put the file and opened it.) I do some more work on it; this time as I save (or maybe it auto-saves) the data gets written to the storage file without any more interaction because the file already exists. Next year I've switched allegiance to UltraAnimate.com, so while cleaning house I go through my Web Documents folder, see the old SooperAnimator.com Data file, and trash it to save disk space. This seems to end up as a combination of the local storage API with some of the behavior of the filesystem access proposal (which to be honest I haven't read yet.) In essence the entire local storage object space is implemented as a key-value DB file. Does this seem reasonable? —Jens
Re: [whatwg] Proposal for local-storage file management
2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com: I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian If we added the ability to create File objects, which could then be stored in localStorage (and WebSQL or whatever will replace it), then wouldn't we basically have the functionality you seek? What's the difference between sticking a File in the foo/bar/bin property on the localStorage object, vs. sicking a File object in the foo/bar/bin directory in some FileSystem object? Note that the latest HTML5 drafts allow for storing File objects in localStorage. / Jonas
Re: [whatwg] Spec comments, sections 3.1-4.7
On Sun, 16 Aug 2009, Aryeh Gregor wrote: On Sun, Aug 16, 2009 at 6:52 AM, Ian Hicksoni...@hixie.ch wrote: They can follow the links (not following the links is a should not, not a must not). Once they follow the links, they must ignore the type= attribute and only take into account the MIME type provided by the server. I was assuming that they don't want to follow unnecessary links. For instance, their spiders can likely only make X requests per second to each domain (due to robots.txt or generic don't be a jerk policies), and if the spiders are forced to make a large number of useless requests then their indexing of any given site will be slowed down. I'm not clear on what it means that you must assume something, actually. An assumption, by definition, might be discarded at any point if more evidence comes in, so a required assumption sounds oxymoronic. Anyway, assumption is a state of knowledge rather than an actual action, so I can't figure out what the requirement means in practice. At this point the user agent seems to have only one choice to make: fetch the resource, or don't. Whether to fetch the resource is, as you point out, explicitly a should requirement. So what's the must assume requirement meant to add? Are there other decisions the user agent has to make before it has the resource available? Sure. For example, the UA might want to display the list of resources to the user. In such a UI, if the UI includes types, it would have to use the type= attribute's value as the type. For Web browsers, this problem only occurs if at least one major browser violates the spec. Until one does, the browsers can just refuse to render the site -- since all the browsers will be doing the same thing, the site cannot legitimately blame the browers. Unless the problem is non-obvious to authors but significant to some consumers (but not enough to make authors widely aware of it). My hypothetical scenario had authors providing an incorrect type= attribute. Perhaps all browsers supported both types anyway, so they retrieved the resource thinking it was type X, then determined it was type Y and processed it as that with no errors being raised. But then if one browser (or search engine, etc.) happens to support type Y but not type X, you get bugs. Another example that I think you yourself have mentioned in the past is Opera's mobile version. It deliberately mangles display in a nonstandard fashion to better fit on a small screen. Again, here the problem isn't obvious to most authors (since they didn't test on small screens), but the implementor is able to improve experience for a significant market of consumers if they ignore the standards. I guess I don't understand what you're asking for the spec to do. Do you want to drop the type= attribute altogether? Probably a little (forms have been pretty successful despite a horrible styling story for over a decade) Because it's impossible to achieve the same functionality as forms -- dynamically building a GET request based on user input, or any POST request at all -- any other way without requiring JavaScript. (Which locks out some users, and is harder to write.) And until a few years ago, when XHR became widely supported, AFAIK it wasn't possible to permit POSTs (necessary for large amounts of input, for instance) even with JavaScript. People use forms now, still, despite this situation having changed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, Aug 27, 2009 at 7:48 PM, Ian Hicksoni...@hixie.ch wrote: Sure. For example, the UA might want to display the list of resources to the user. In such a UI, if the UI includes types, it would have to use the type= attribute's value as the type. That seems very speculative. Does any UA actually do anything like this, with links or anything else? I guess I don't understand what you're asking for the spec to do. Do you want to drop the type= attribute altogether? No, I just thought this particular requirement should be should instead of must. Or should be dropped entirely, since it seems very vague to me and I'm not clear what real-world scenario it addresses. But it doesn't really matter and isn't worth spending time arguing over if you don't agree.
Re: [whatwg] Proposal for local-storage file management
Not sure I agree with limiting it to the duration of the page. For instance, if I'm Flickr, I want to be able to get access to the My Photos directory and monitor it for new photos being added. Additionally, if I've given you access to the directory once, you can do most of the damage you want with that one-time access. The existing API has a parameter on many of the functions called persistent - I think the challenge is how to surface that in a reasonable UI. I believe though that it is worth trying. From the proposal - The last argument to browseForDirectory is a Boolean argument determining whether the mountpoint is to be made persistent across restarts of the application. If this argument is missing, it is assumed to be present, with a default value of false. If the argument is true then the File object must be marked as persistent. 2009/8/27 Linus Upson li...@google.com I like this proposal. It was what I had in mind with input type=open and input type=save. The only small change I'd make is that the page can only maintain a reference to the file for the life of that page. After that, the user needs to click open again. The open and save dialogs may remember recent files to make it easy for the user. Linus 2009/8/27 Jens Alfke s...@google.com [This is a spin-off of Web Storage: apparent contradiction in spec. I'm starting a new thread to make a specific proposal.] I agree that where possible we should find a way to do things without adding Mother-may-I dialog boxes. But I also believe we need some user interaction to enable a site to store nontrivial amounts of permanent local data, to avoid Linus's griefer scenario. Conundrum. But maybe the user interaction can be made to fit into existing familiar workflows. In a traditional document-based UI, the app prompts the user with a standard Save dialog box when it needs to create a new data storage area (a file). A default name and location are filled in, but the user can customize, or of course hit Cancel. Why not re-use that same model for HTML5 local storage? After all, we know the data is going to end up in the filesystem, so why not let the user pick where to put it? This way every web-app gets a separate local file. Internally it's probably a sqlite database or DBM file or whatever, but that's unimportant. The user follows the age-old save-a-file workflow to create one, so s/he is in control of whether it's created and where it goes. It gets backed up along with the user's other data. The user can trash it later on to make room or for privacy purposes. Here's what a typical scenario might look like: Ellen tells me about a great online animation program. I go to its site, and it puts up a Canvas and a bunch of snazzy drawing tools, so I start sketching frames of an animation. (Behind the scenes, the app is storing my drawings in session storage. This is considered temporary, so the browser gives it a reasonable quota without any user interaction.) After a while I decide I want to keep using the app, and the stuff I've drawn has potential, so I decide to save it to disk. I click the Save button, and the site (actually the browser) puts up a standard Save dialog box. (Behind the scenes the JS code is writing a value to persistent local storage, and since no storage exists yet for its domain, the browser is prompting the user.) The dialog's prompt is something like Save SooperAnimator.com data as:, and the initial destination is ~/Documents/Web Documents/SooperAnimator.com Data. I hit Enter and my animation is saved. (Behind the scenes the browser created a new local-storage file at that location, and remembered where it put it.) Next month I remember that animation in progress and go back to the site. My work appears just the way I left it. (The site's script accessed its persistent storage, so the browser looked up where it put the file and opened it.) I do some more work on it; this time as I save (or maybe it auto-saves) the data gets written to the storage file without any more interaction because the file already exists. Next year I've switched allegiance to UltraAnimate.com, so while cleaning house I go through my Web Documents folder, see the old SooperAnimator.com Data file, and trash it to save disk space. This seems to end up as a combination of the local storage API with some of the behavior of the filesystem access proposal (which to be honest I haven't read yet.) In essence the entire local storage object space is implemented as a key-value DB file. Does this seem reasonable? —Jens
Re: [whatwg] the cite element
On Sun, 16 Aug 2009, Benjamin Hawkes-Lewis wrote: On 16/08/2009 12:21, Ian Hickson wrote: Italics is the right format for almost all titles of works. How are you measuring that? For example, chapters in collections and articles are works and have titles, and those titles aren't typically distinguished with italics, at least in English. Titles of works are commonly distinguished from surrounding text and italics is a common format for many titles of works would statements that would be hard to argue with. The spec lists these cases: # a book, a paper, an essay, a poem, a score, a song, a script, a film, a # TV show, a game, a sculpture, a painting, a theatre production, a play, an # opera, a musical, an exhibition, a legal case report, etc Of those, all would be typically marked up in italics except maybe games and exhibitions. I'm not saying it's _always_ right. Just that it's right often enough to be the default. On Mon, 17 Aug 2009, Brian Campbell wrote: On Jul 19, 2009, at 5:58 AM, Ian Hickson wrote: Certainly there are situation-specific cases where names might be styled, but I think it's mostly as a side-effect of location rather than because the text is a name. Consider: aside class=testimonial qBest value for the money!/q J. Random User /aside aside class=bookquote qBest value for the money!/q A Random Book /aside aside class=review qBest value for the money!/q Newspaper /aside aside class=logfiles q[23:02] evaluator: best value/q filename.log /aside Hmm. Isn't the common theme here that those names are a source that is being cited (either a work or person)? For many authors, when writing stylesheets to apply to these types of uses, it makes more sense or is easier to have a specific element to style, rather than simply a text node that is a sibling of a q and/or a descendent of a particular class of aside. I think these cases would typically be styled in all kinds of ways that are going to require class attributes anyway, so the need for a span for the second part of these examples is a non-issue. Earlier, when justifying why you changed the definition of cite from HTML 4.01, you said: I don't think it makes sense to use the cite element to refer to people, because typographically people aren't generally marked up anyway. I don't really see how you'd use it to refer to untitled works. This usage is an example of when people are typographically marked up. It's a minor case. The semantic here wouldn't be name of person, it would be name of person when immediately following a quote in a pullquote, which is far too specific to deserve a whole element. And there are numerous examples of this use, which seem to contradict this argument: HTML4 actually defined cite more like what you describe above; we changed it to be a title of work element rather than a citation element because that's actually how people were using it. Among them (selected from some I have run across myself, as well as some from Philip Taylor's data): * http://www.webporter.com (from Philip Taylor's data) cite is used to mark up the source of a testimonial. The markup in this case is all sorts of wrong -- e.g. the citation is inside the quote -- and, more importantly, the element's style is made non-italics, thus completely defeating the entire point of marking up the element in the first place. This page is an argument to not have cite cover people's names. * http://www.thesentencegame.com/ (from Philip Taylor's data) cite is used to mark up the user who wrote or drew a particular piece of content. Yup, this is one of the very few examples of marking up names with cite. * http://en.wikipedia.org/wiki/RNA_interference (from Philip Taylor's data) cite is used to mark up a full bibliographic citation. Also used on other pages on Wikipedia. This is a good example of cite being more useful if used only for titles, given that cite is being un-styled then a span inside it is being restyled to italics. The HTML5 definition would have cite only used for the italics part, thus making the styling simpler. * http://www.igofigure.com/page/testimonials/ cite is used for the source of a testimonial. * http://thelede.blogs.nytimes.com/2009/07/14/running-with-the-bulls-in-pamplona/ (and other articles on the NY Times Blogs) cite is used to mark up the author of a comment. * http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 In the very example given in HTML 4.01, cite is used to mark up the author of a quote. * http://diveintomark.org/archives/2009/04/07/hhgregg-doa cite is used to mark up the author of a comment. * http://diggingintowordpress.com/ThemePlayground/index.php?wptheme=H5%20Theme%20Template Even some folks who are trying to use HTML5 are using cite to mark up the author of a comment; take a look at the
Re: [whatwg] Proposal for local-storage file management
Things missing from Arun's File proposal as is, off the top of my head: a) a directory structure (someone would have to build one on top of it... not critical, but not ideal) b) Ability to store it not in localStorage in some hidden directory, but on the part of the filesystem the user is familiar with (e.g. if I edit a picture, I don't want to store it in localStorage tucked away under local settings\user data\..., I want to save it in /home/ifette/photos/blah.jpg). Don't make the browser a silo. c) ability to map in a directory and make sense of that. I want Picasa / Flickr / Facebook to be able to see oh look, there's a new file in /home/ifette/photos/ - let's act on that.) d) Ability to read/update parts of the file. Could be used similar to blob builder for building up a form post that I then send off. Or could be used to manage an offline mail database, assuming I don't want to shove my mail into a sqlite database. For this it's desirable that I be able to efficiently fseek(), fread(), and fwrite() segments of the file. 2009/8/27 Jonas Sicking jo...@sicking.cc 2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com: I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian If we added the ability to create File objects, which could then be stored in localStorage (and WebSQL or whatever will replace it), then wouldn't we basically have the functionality you seek? What's the difference between sticking a File in the foo/bar/bin property on the localStorage object, vs. sicking a File object in the foo/bar/bin directory in some FileSystem object? Note that the latest HTML5 drafts allow for storing File objects in localStorage. / Jonas
Re: [whatwg] Proposal for local-storage file management
2009/8/27 Jonas Sicking jo...@sicking.cc 2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com: I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian If we added the ability to create File objects, which could then be stored in localStorage (and WebSQL or whatever will replace it), then wouldn't we basically have the functionality you seek? What's the difference between sticking a File in the foo/bar/bin property on the localStorage object, vs. sicking a File object in the foo/bar/bin directory in some FileSystem object? +1 the call to add a file system like api to the storage mix Enumerating the contents of a 'directory' is one difference. Recursively deleting a 'directory' is another. Checking creation/modification timestamps is a third. The LocalStorage big-hashmap model doesn't work well for these things in its current form. The hierarchical file system abstraction is well understand and has a long track record of usefulness. From a windows programmer point of view * LocalStorage is akin to the registry. * FileSystem is akin to the file system. * Databases is akin to structured storage. * AppCache is a necessary evil to do anything without a network connection. * Workers are akin to threads/processes * GlobalScripts/SharedContext/ApplicationContexts are akin to DLLs. Note that the latest HTML5 drafts allow for storing File objects in localStorage. / Jonas
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Sun, 16 Aug 2009, Kristof Zelechovski wrote: 1. What counts for script source if the inline XML contained within the SCRIPT tag is invalid, assuming that the document is HTML or the document is XHTML and the embedded invalid XML code is within a CDATA section so that the containing XHTML document is valid? Could you give an example of what you mean? Maybe we are misunderstanding each other. I don't see how you can have any inline XML in text/html script (except, I guess, if another script generates it using the DOM), and ill-formed XML in an XML document causes the parser to abort long before we get to the script processing. 2. Why don't you say that the script source for text/javascript is the AST? How would declaring the script source to be the embedded text break XML-based script languages? The interpreter can parse the XML text itself, can't it? (AST?) The whole point is that if the script is XML, there's no text to parse -- it's already a DOM. 3. In general, I am asking that XML be treated just as all other script types, unless you allow XML data in a SCRIPT element, where the execution of such data means creating a new XML document and attaching it to the SCRIPT element as a property for other scripts to peruse. This is how it works in Internet Explorer. Of course, such a script cannot be used to handle events in the containing document. Example: SCRIPT ID=M TYPE=text/xml root //SCRIPT SCRIPT TYPE=text/vbscript !-- MSGBOX TYPENAME(DOCUMENT. GETELEMENTBYID(M). XMLDOCUMENT),, XML DOCUMENT REM --/SCRIPT There's no XML there, at least not in the sense used by the HTML5 spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for local-storage file management
2009/8/27 Michael Nordman micha...@google.com 2009/8/27 Jonas Sicking jo...@sicking.cc 2009/8/27 Ian Fette (イアンフェッティ) ife...@google.com: I would much rather have a well thought-out local filesystem proposal, than continued creep of the existing File and Local Storage proposal. These proposals are both designed from the perspective of I want to take some existing data and either put it into the cloud or make it available offline. They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem (e.g. if I'm flickr and I want to be able to read the user's My Photos folder, send those up, but also make thumbnails that I want to save locally and don't care if they get uploaded, maintain an index file with image metadata / thumbnails / ... locally, save off some intermediate files, ... For this, I would really like to see us take another look at http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this spec is exactly what we need, but I like the general approach of origins get a virtual filesystem tucked away that they can use, they can fread/fwrite/fseek, and optionally if they want to interact with the host FS they can request that and then get some sub-set of that (e.g. my documents or my photos) mapped in. -Ian If we added the ability to create File objects, which could then be stored in localStorage (and WebSQL or whatever will replace it), then wouldn't we basically have the functionality you seek? What's the difference between sticking a File in the foo/bar/bin property on the localStorage object, vs. sicking a File object in the foo/bar/bin directory in some FileSystem object? +1 the call to add a file system like api to the storage mix Enumerating the contents of a 'directory' is one difference. Recursively deleting a 'directory' is another. Checking creation/modification timestamps is a third. The LocalStorage big-hashmap model doesn't work well for these things in its current form. The hierarchical file system abstraction is well understand and has a long track record of usefulness. Drive by comment: I'm not saying that it'd be a replacement for a better file system API, but it might be nice to add range iteration to LocalStorage. Of course, in order to do that, it'd need to be stored in a tree rather than a hash table.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Mon, 17 Aug 2009, Max Romantschuk wrote: Silvia Pfeiffer wrote: Precision is influenced more strongly by the temporal resolution of the decoding pipeline rather than the polling resolution for currentTime. I doubt the previous implementations of start and end gave you a 3 sample accurate resolution even for wav files. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. A reasonable forward-compatible solution would be to allow (by whichever method settled upon) millisecond-resolution to be specified for setting/resetting from where/to play the clip. User agents could implement a best-effort, not needing to guarantee any specific resolution at this point. As far as I can tell, HTML5 already allows this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A tag for measurements / quantity?
On Mon, 17 Aug 2009, Max Romantschuk wrote: Ian Hickson wrote: I don't really understand the use case here. What problem would this be solving? What do we have to demonstrate that this problem matters? It might well be that there is no problem. Ok. Then I recommend we punt this to the next version. From a practical perspective it would be nice to have an unambiguous way to mark up numerical constants in a document and thus allow a straightforward way of doing conversions. Personally, the obvious use case for me is recipes. Even a relatively simple one requires a lot of manual calculation to convert cups, pounds and ounces into deciliters and grams. While some sites supply conversion tools for this providing the semantic information straight in the markup would allow conversions for any document. With the large majority of humanity doing cooking one could argue that this would be genuinely useful. Then again, it's quite possible no one would ever use this, and it would just end up cluttering the spec. I can't imagine really seeing enough sites using this to make it worth it, but maybe our experience with time will show this kind of thing is used a lot. On Wed, 19 Aug 2009, Jeremy Keith wrote: The problem statement on the microformats wiki page reads: Measures (e.g. weights, sizes, temperatures) occur frequently on the Web, they are constituted of a value a unit-measure and, in scientific and technical contexts, an experimental uncertainty. These 3 elements should be marked-up consistently across websites so that they can be easily identified and acted upon (export, compute, convert) in collaborative distributed applications. Unit-measures differ from locale to locale (e.g. Fahrenheit vs. Celsius, pound versus Kilogram), making comparison and matching of offerings difficult. The measurement microformat will enable unambiguous description of physical quantities and thus provide a solid ground for data sharing and automation in many areas. This is begging the question. Just because a pattern occurs a lot doesn't mean that it should be marked up. But I guess if the microformat is successful, we'll have the data we need for the next version of the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Aug 27, 2009 at 10:33 AM, Linus Upsonli...@google.com wrote: I don't think there is consensus at Google yet. I'm not saying that UAs shouldn't provide file-like lifetime semantics for storage. I'm just saying the user should decide, not the web page. Linus, are you only considering traditional in-browser web apps that don't go through an install process of any sort (i.e., I go to a URL in my web browser)? Would you hold a different opinion for different types of HTML5-based applications (like the TiddlyWiki app that gets copied locally)? Or would you require that all apps go through an install process that acquires quota, permissions, etc.? It seems like others are objecting to your position based on different application models than the ones you have in mind. -- Dirk
Re: [whatwg] Spec comments, sections 3.1-4.7
On Thu, 27 Aug 2009, Aryeh Gregor wrote: On Thu, Aug 27, 2009 at 7:48 PM, Ian Hicksoni...@hixie.ch wrote: Sure. For example, the UA might want to display the list of resources to the user. In such a UI, if the UI includes types, it would have to use the type= attribute's value as the type. That seems very speculative. Does any UA actually do anything like this, with links or anything else? Opera has a UI to show a list of links. But even if nobody had any UI like this, I'm not sure it really matters. The point is that the type= attribute is to be considered authoritative until the server can provide the real type. I guess I don't understand what you're asking for the spec to do. Do you want to drop the type= attribute altogether? No, I just thought this particular requirement should be should instead of must. I don't see what reason a tool would have to ignore this requirement. The one requirement that might be ignored (namely, not downloading the resource if the type isn't supported) _is_ a should. Or should be dropped entirely, since it seems very vague to me and I'm not clear what real-world scenario it addresses. Without it, I don't really see what the type= attribute would do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec comments, section 4.8
On Mon, 17 Aug 2009, Aryeh Gregor wrote: It's kind of a nitpick, but I don't think this sentence is accurate: Another example of an image that defies full description is a fractal, which, by definition, is infinite in complexity. First of all, we're talking about describing images here, which are presumably projected onto finite-resolution displays, and which are certainly being processed by finite-resolution retinas. Visually, it's not possible for anything to have infinite complexity. Second of all, mathematically, fractals are rather interesting things, but infinite in complexity is not a correct description by any definition of complexity I'm aware of. Fractals are often generated by very simple definitions or computer programs, so they have low Kolmogorov complexity. Something like a Sierpinski triangle is very simple to explain, understand, draw, and picture. You could describe one like this: An equilateral triangle pointing upward. A downward-pointing triangle of half the height has been removed from the middle, leaving three upward-pointing triangles each half as tall as the original. From each of those three, another downward-pointing triangle has been removed, leaving nine quarter-height triangles, and so on ad infinitum. That's an accurate and precise description. I'm not sure fractals are a good example here at all. But if they are, at least the text , which, by definition, is infinite in complexity should be removed. I've changed complexity to detail. Since the image could be an animated SVG continuously zooming into one point, I don't think the use of finite-resolution displays prevents the images from being, for all intents and purposes, infinite. The NETWORK_LOADED state is described (normatively) as The entire media resource has been obtained and is available to the user agent locally. Network connectivity could be lost without affecting the media playback. This suggests to me that it would be incorrect for this to be the state of the resource if, during playback of a lengthy video, the user agent began deleting the already-played earlier part of the video, so that the full data was no longer available. However, the resource fetch algorithm sets NETWORK_LOADED regardless of whether earlier parts of the resource are still available, and nothing I can see ever changes the network state from NETWORK_LOADED to any other state. This seems contradictory, or at least confusing. Fixed. There are some Unicode characters (U+231B? an hourglass?) here that are showing up as white boxes for me at the beginning of some of the list elements. You need a better font. HTTP partial range requests sounds odd to me, and partial range is redundant. Maybe just HTTP range requests? The HTTP spec uses range retrieval requests. Changed to HTTP range retrieval requests. The user agent cannot be in this state if playback has ended, as the current playback position can never advanced in this case. advanced - advance? Fixed. If the attribute is absent, then the user agent should avoid making a user interface available that could conflict with an author-provided user interface. User agents may make the following features available, however, even when the attribute is absent: User agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu. This doesn't make a lot of sense to me. I would have expected a list of features after the first quoted paragraph, but instead there's another paragraph that partially repeats the content of the first paragraph. It reads like it originally said something different, and then something was chopped out and not patched up properly. Fixed. This isn't really a comment, since it's too late to change it, but I'm curious: why is the default that the author provides controls, instead of the UA? It seems like it would be simpler for the UA to supply controls unless the author opts out. Would you expect many authors to manually supply controls? I do not recall. Is The user agent stops fetching the media data before it is completely downloaded really a good description for abort? It can trigger during the NETWORK_LOADED state, can't it? Also, doesn't it only fire when the load is aborted by the user or a script? Not sure what you mean. When else would it abort? What other description would you use? play and playing have confusingly similar names. Do you mean the events? If so, then I agree. Not sure what to do about it. On Tue, 18 Aug 2009, Kevin Benson wrote: [...] Their purpose is described later in 4.8.10.5 Loading the media resource at step 20: (Steps in synchronous sections are marked with ⌛.) and
Re: [whatwg] Proposal to drag virtual file out of browser
On Mon, 17 Aug 2009, Jian Li wrote: The HTML 5 spec defines the event-based drag-and-drop mechanism that could cross the browser boundary. If a draggable element contains a URL, dragging it out of the browser will only copy the URL value. However, in some scenarios, we really want to download the data file from the specified URL, instead of copying the value. Here we propose a way to allow dragging a virtual file denoted by an URL out of the browser boundary. I haven't added this to HTML5, since we've only just gotten as far as getting drag and drop of files _in_ to HTML. However, I've noted this for a future version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Mon, 24 Aug 2009 19:31:30 -0400, Ian Hickson i...@hixie.ch wrote:
On Fri, 14 Aug 2009, Michael A. Puls II wrote:
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson i...@hixie.ch wrote:
- Should objects exist all the time whether they are attached to
the
document or not?
Assuming you mean the plugins, as opposed to the elements themselves,
then
the way the spec is written, the plugin instantiates regardless of
whether
it is in the document or not.
Are you saying that in the following case (for the Netscape 6.4 WMP
plug-in
(the liveconnect-supported one) for example):
script
var obj = document.createElement(object);
obj.setAttribute(type, application/x-mplayer2);
//document.documentElement.appendChild(obj);
window.onload = function() {
setTimeout(function() {
alert(obj.SetFileName);
//document.documentElement.removeChild(obj);
//alert(obj.SetFileName);
}, 1);
};
/script
that .SetFileName() (a function the plug-in supports), will be
accessible even if the object hasn't been attached yet? Are you also
saying that if it is attached and you remove it from the document that
SetFileName will still be callable?
Yes.
If so, that's not what happens in Opera. Pulling the object out of the
document nukes the plug-in instance and an instance isn't created until
you append to the document. Firefox behaves that way with plug-ins too.
And, I think that behavior is required for compat.
If it is required for compat, then we should change the spec. Can you
confirm that this is the case? Generally, having elements act different
out of document is something I'm trying to avoid.
I urge browser devs to comment more on the technical side of this, but:
Here's an example that uses a more modern plug-in that shows what browsers
do.
window.onload = function() {
var obj = document.createElement(object);
obj.type = application/x-shockwave-flash;
obj.data = http://adobe.com/shockwave/welcome/flash.swf;;
obj.width = 320;
obj.height = 240;
//document.body.appendChild(obj);
//obj.style.display = none;
setTimeout(function() {
alert(obj.SetVariable);
}, 1000);
};
In other words, for a plug-in to be initialized (and scriptable if it's
capable):
1. Its element must be attached to the document.
2. Its element must not be set to display of 'none' (and therefore must
not be part of fallback content that's not triggered yet).
As soon as any one of those conditions are not satisfied, the plug-in
instance is destroyed/gone/not accessible.
3. For flash (non-activex-version) at least, in window modes other than
'window' (like 'opaque' and 'transparent'), the plug-in won't *fully*
initialize (as in, it won't paint and start fetching data) until you
scroll the element into view. Firefox, Opera and Safari do this at least,
and it's actually quite nice most of the time that things work that way.
You can see this behavior on songza.com and blip.fm sometimes. You can
also see this on very tall pages with lots of flash player objects
attached.
I believe these things are all necessary for resource management and a
good user experience and are now expected.
Examples:
If you remove a plug-in object from the document, it shouldn't be
lingering around in memory and using other resources, especially if you're
replacing it with another object.
If you initially set an object to display: none and plan to flip its
display later to load a plug-in, you wouldn't want the plug-in to
initialize before then.
You also might want to turn a plug-in off by setting an object to
display: none.
Imagine a site where you have 2 plugin objects: one for a flash youtube
player and one for a flash audio player from another site. You might only
want to have the instance running that's applicable for the track being
played. Songza.com was an example of a situation where this could be
applicable. They seem to *only* be using the youtube player now now.
If HTML5 says differently, it's really contradicting current browser
behavior. Changing browser behavior to match HTML5 would not match the
expectations of authors and page behavior.
I can't vouch whether vendors are willing to change things in these areas,
but it sounds really risky.
--
Michael
Re: [whatwg] Web Storage: apparent contradiction in spec
My concerns are around browser UAs. AIR, Dashboard, XULRunner, Extensions, etc. can have different policies. I simply want clicking on links in my browser to be safe. Linus On Thu, Aug 27, 2009 at 5:53 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Aug 27, 2009 at 10:33 AM, Linus Upsonli...@google.com wrote: I don't think there is consensus at Google yet. I'm not saying that UAs shouldn't provide file-like lifetime semantics for storage. I'm just saying the user should decide, not the web page. Linus, are you only considering traditional in-browser web apps that don't go through an install process of any sort (i.e., I go to a URL in my web browser)? Would you hold a different opinion for different types of HTML5-based applications (like the TiddlyWiki app that gets copied locally)? Or would you require that all apps go through an install process that acquires quota, permissions, etc.? It seems like others are objecting to your position based on different application models than the ones you have in mind. -- Dirk
