Re: [whatwg] html5 state handling: overview and extensions
On Mon, 15 Jun 2009, Mike Wilson wrote: A naive solution for this would be to add something similar to a browser_context-scoped cookie. There have been several requests for things along these lines; I'd recommend taking them up with the working group working on cookies. Invisible Document state for GET requests There currently is no support for associating invisible state with a Document delivered with GET. This is also an area where web frameworks have worked around this problem, and typical workarounds are to use url-based (visible) state or to switch to POST instead. This is by design, as I understand it. It sounds like a feature request for the HTTP working group, though. Going forward I would expect authors to use AJAX-like interaction models so that there is only one page, and the state is all scripted. Document state There currently is no support for associating script state on the Document level. Any state saved in DOM or script global object will be lost on a page reload. You can use pushState() to add an entry if your state changes relative to the original state described in the resource. Use cases would include single-page Ajax applications that want to store data independent of a certain history entry, but at the same time not sharing it with other page loads (Documents) of the same application in the history of the same browsing context (otherwise sessionStorage could be used). That's not a use case, that's a description of what it enables. When would this ever happen? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] html5 state handling: overview and extensions
Michael Nordman wrote: This breakdown is a useful way to think about application state in the browser. Thanks, it has been very useful to myself as a working model for making vague thoughts of something missing into something that is possible to measure and compare. Ideally, some similar kind of overview could be maintained in the HTML5 spec to keep both spec authors and readers sane. Another axis that could be incorporated into the model is lifetime. You really hit the nail on the head there. Actually, my initial attempt on a comparison table included a few additional columns: General: - state inherited by cloned browsing context - persistent storage supported - state protected/scoped by origin - state protected/scoped by origin+path - lifetime control Server-control: - state travels to browser in response headers - state travels to browser in response body but I decided to start out with a cut-down version, as otherwise definitely no-one would read my post (it was bad enough with the length of it even being cut down ;-). There is some overlap between Server- Controlled and Script-Controlled realms in cookies, applications definitely have a dependency on that overlap being there. Right, I missed including that in the post. Actually, in my initial table (mentioned above) I didn't split between client- and server-control, but had that as columns instead, so one feature (cookies) could cover both script- and server-needs. I should note that in this initial table of mine, normal cookies serve both purposes but http-only cookies only do server-controlled state. Here's an updated table with cookies added: SCRIPT-CONTROLLED STATE Scope Visibility : State construct - -- - user agent, invisible : cookies, WS localStorage browsing context, invisible : window.name, WS sessionStorage document, invisible : - history entry,invisible : history state history entry,url, : url hash There are two constructs not represented in your writeup, Database and ApplicationCache. Yes, they felt like somewhat different animals so I didn't include them, maybe that was wrong. All the other ones are some kind of simple data or name/value-paired data so I focused on them. My goal was also to make a matrix that would help us find the missing pieces, by identifying the empty cells. When adding too many different animals to the same matrix there will be many empty cells, and it gets harder to see patterns. Do you have ideas on how to incorporate Database and ApplicationCache in the comparisons? Possible solutions would be to add a new documentStorage to WebStorage, or to offer a History.setDocumentState method. I see other possibilities with WebStorage too. documentStorage has persistent lifetime + document scope others... transient lifetime + document scope (transient does not survive a browser restart) transient lifetime + user agent scopetemporaryStorage transient lifetime + history entry scope privateStorage Interesting ideas! My initial thought was that lifetime could be controlled in a way similar to cookies, ie no lifetime indicates transient lifetime, and for persistent lifetime you set an expiration date/time. Maybe the legacy of cookie expiration doesn't have to be the model here, but it would seem good if some of the suggested extensions are indeed implemented as something cookie-like. mvh Mike
Re: [whatwg] html5 state handling: overview and extensions
This breakdown is a useful way to think about application state in the browser. Another axis that could be incorporated into the model is lifetime. There is some overlap between Server-Controlled and Script-Controlled realms in cookies, applications definitely have a dependency on that overlap being there. There are two constructs not represented in your writeup, Database and ApplicationCache. Possible solutions would be to add a new documentStorage to WebStorage, or to offer a History.setDocumentState method. I see other possibilities with WebStorage too. documentStorage has persistent lifetime + document scope others... transient lifetime + document scope (transient does not survive a browser restart) transient lifetime + user agent scopetemporaryStorage transient lifetime + history entry scope privateStorage
[whatwg] html5 state handling: overview and extensions
INTRODUCTION HTML5 provides a number of constructs to transfer and manage application state. In this post I attempt to classify these constructs in a consistent manner to identify what kinds of state management is taken care of, and what is not. My goal is to discuss the uncovered areas to see if we can address them with suitable additions to HTML5. DEFINITIONS State To simplify this overview I limit myself to only addressing internal state that the application stores to keep track of the user's interaction with it, and that isn't directly accessible by the user. This means f ex that hidden input fields are included in this overview (as these usually represent some internal state) but editable input fields are not (as these correspond more to page parameters than page state). I know this distinction may not be perfect, and at some point we might want to include the other parts, but I think it is good to start out with these restrictions. State can be stored in many different ways, and many different things can be regarded as state, so consider the below scenario to understand what I regard as state in this post: - a user makes some navigation action that makes the browser navigate to, and request http://host/page1 - when returning the response for page1, the server may include some state (ServerState) to be stored in the browser through some state construct - during the lifetime of the returned page in the browser, additional state may be produced by script (ScriptState) and stored by some other state construct - to qualify as state constructs in this overview, the constructs used to store ServerState and ScriptState above should support that the state survives the following actions: . navigating away from, and then back again, to the current session history entry in the browsing context, including scenarios where the document objects have been discarded in the meantime . page reload/refresh of the current page (this follows from the first point) (there are many other actions that could be mentioned but the above two are enough for this overview) State that survives these criteria is real state in the browser. Server-controlled state This is state which is created by the server application and then transmitted to the browser where it is stored, to later be transparently sent back to the server for identification or processing. As it is under server control it should not rely on script execution in the browser, so state constructs need to have a mechanism that both automatically stores the state in browser, and automatically transfers it back from browser to server when appropriate. Typically the transfer back and forth between server and browser takes place on at least every page request and response. Script-controlled state This is state created and stored by script in the browser. The preservation of state only applies to other script reading the data and any mechanism for transfer back and forth to the server is optional. Scopes State can be stored on different scopes, or contexts, to control its reach and lifetime. HTML5 offers the following scopes where a higher item on the list encloses lower items: - User agent (an application containing a collection of top-level browsing contexts) - Browsing context (has session history with a number of Documents) - Document (corresponds to one page load from server but can be associated with multiple session history entries with different navigational states) - Session history entry (a single navigational state for a Document) Apart from the different scopes, state is also kept separated by origin, to not allow different sites to interfere with each other's state. I will just assume origin is in effect for the rest of this post. User visibility For different scenarios it may, or may not, be desired to indicate the current state to the user through the browser user interface. This could f ex mean being part of the URL for bookmarkability etc. It is an advantage if the application author can choose between state constructs both with and without user interface exposure. Request type (http method) Some state constructs are unique to a certain http method. In this overview I list GET and POST methods. FEATURE TABLES Below are tables comparing properties of different state constructs. There are many alternatives to how these tables could be organized but I've tried to keep things simple and only add columns for the most important properties for this discussion. SERVER-CONTROLLED STATE Scope Visibility Request : State construct - -- --- - user agent, invisible, GET : cookie user agent, invisible, POST: cookie browsing context,
