Re: Identifying Application State

TAG members:

Are you ready to vote to approve this as a TAG finding on this week's call? 
If not, please read it and resolve issues as necessary, so we can vote on 
the 8th. Thank you!


On 11/23/2011 12:32 PM, ashok malhotra wrote:
> We received two comments on the final version version of
> IdentifyingApplicationState.
> See
> A revised version addressing these comments is available at:
> All the best, Ashok
> On 9/27/2011 5:45 AM, ashok malhotra wrote:
>> The TAG expects soon to publish a Finding titled "Identifying Application
>> State". A final draft is now available at [1] for review by the
>> community. We request that you send any comments to the
>> mailing list by 28 October 2011.
>> From the abstract:
>>     /"As the Web has evolved from a Web of documents to a Web of
>>     applications, techniques for designing applications so that
>>     application state and document views of application state can be
>>     identified and bookmarked have evolved correspondingly. Originally
>>     introduced as a static "fragment identifier" to identify locations in
>>     a document, the hash sign, #, is now being used to identify
>>     application states as well as in other interesting ways, for example,
>>     by SVG and PDF to select from and render documents and as arguments
>>     to Web applications that are interpreted by JavaScript. Fragment
>>     identifiers are used to provide several different kinds of parameters
>>     to the client-side application, such as the actual URI of a video to
>>     be played to a video player, or the position and zoom to a map. In
>>     many widely deployed browsers, changing the scheme, path or query
>>     string in a URI causes an unconditional page reload, but changes to
>>     the fragment identifier do not: the characters in the URI bar after
>>     the # can be changed without incurring the overhead of reloading the
>>     page. Applications and toolkits using fragment identifiers in this
>>     way often go to some effort to maintain a history and make sure the
>>     back button works as expected. Accessibility and search can, however,
>>     be compromised, because without running JavaScript, the URI has no
>>     meaning. Such uses of the "fragment identifier" have interesting and
>>     different properties, and the usage differs from the way it is
>>     described in existing specifications. Recently added functionality in
>>     [HTML5] (history.pushState() and history.replaceState()) allows
>>     browser history to be changed without causing a page reload thereby
>>     providing an alternative to the use of fragment identifiers to
>>     identify application state.
>>     Many Web applications are used to present or edit documents. Such
>>     applications should be designed so that the documents are readily
>>     identified with URIs that can be used for linking from other Web
>>     pages or transmitted in e-mails or used in copy/paste situations.
>>     This document explores the issues that arise from these new uses of
>>     fragment identifiers and attempts to define best practices. We argue
>>     that, in many cases, the use of query parameters along with the new
>>     HTML5 functionality mentioned above is preferable to fragment
>>     identifiers to identify application state."
>>     /
>> TAG Findings (complete list at [2]) are notes that convey the TAG's
>> opinions on various matters relating to Web Architecture. TAG Findings
>> are not W3C Recommendation-track documents, but the TAG welcomes comments
>> and suggestions on our finding drafts.
>> Thank you very much.
>> Ashok Malhotra
>> [1]
>> [2]

Received on Tuesday, 29 November 2011 23:32:20 UTC