- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 29 Jun 2011 07:08:04 -0400
- To: ext Kris Zyp <kris@sitepen.com>, public-webapps@w3.org, Sean Eagan <seaneagan1@gmail.com>
Kris, Sean - in case you were including the W3C re "appropriate next step to advance this proposal", please note the W3C's new Community Groups and Business Groups proposal has now advanced to the Beta stage: W3C Community Groups and Business Groups http://www.w3.org/2010/12/community/ Beta Testing Community and Business Groups http://www.w3.org/QA/2011/06/beta_for_community_groups_unde.html Perhaps a Community Group is a way to advance the proposal below as well other recent proposals discussed on this list that I have noted: = Mouse Lock; Google; 16-June-2011 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1095.html = Spell Check API; Hironori Bono (Google) ; 9-May-2011 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0516.html = DOM Traversal, DOM XPath; Jonas 25-Apr-2011 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0310.html = SearchBox API: Chromium; 20-Mar-2011 http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1017.html -AB On 5/11/11 10:46 AM, ext Kris Zyp wrote: > Is there an appropriate next step to advance this proposal? It seems > like there is interest in this approach. Does it need to be written up > in a more formal spec? > Thanks, > Kris > > On 2/18/2011 10:03 AM, Sean Eagan wrote: >> Very exciting proposal! I hope my comments below can help move it along. >> >> Regarding media type choices, the following two snippets from RFC 5988 >> are relevant: >> >> 1) “Registered relation types MUST NOT constrain the media type of the >> context IRI” >> >> Thus the link context resource should not be constrained to just >> "application/json". Other text based media types such as XML and HTML >> should be applicable as renderable content as well. The proposed >> event interface already includes a subset of XMLHttpRequest, whose >> support for text based media types could be leveraged. To do this, >> the "content" property could be replaced with XMLHttpRequest’s >> "responseText" and "responseXML" properties, and could even add >> "responseJSON" similar to “responseXML” but containing any >> JSON.parse()’ed “application/json” content, and “responseHTML” >> containing an Element with any “text/html” content as its outerHTML. >> Also useful would be “status” and “statusText”, and possibly abort(). >> The DONE readystatechange event would correspond to “onContentLoad”. >> The “onContentProgress” events though might not make sense for >> non-JSON media types. If enough of the XmlHttpRequest interface were >> deemed applicable, the event object could instead include an actual >> asynchronous XMLHttpRequest object initially in the LOADING state as >> its “request” property. In this case, an “onNavigation” event would >> initially be sent corresponding to the XMLHttpRequest’s LOADING >> readystatechange event which would not be fired. This might also >> facilitate adding cross-origin resource sharing [1] support within >> this proposal. >> >> 2) “, and MUST NOT constrain the available representation media types >> of the target IRI. However, they can specify the behaviours and >> properties of the target resource (e.g., allowable HTTP methods, >> request and response media types that must be supported).” >> >> Thus the link target resource media type should also probably not be >> constrained, instead support for html and/or javascript could be >> specified as required. Accordingly, the link relation name should be >> media type agnostic, some options might be “renderer”, “view”, and >> “view-handler”?. HTML does seem to me like it would be the most >> natural for both web authors and user agent implementers, here are >> some additional potential advantages: >> >> * Only need to include one link, and match one URI when searching for >> matching existing browsing contexts to send navigation events to. >> * Could provide a javascript binding to the link target URI via >> document.initialLocation, similar to document.location >> (window.initialLocation might get confused with the window’s initial >> history location). >> * Allows including static "Loading..." UIs while apps load. >> * More script loading control via "async" and "defer" script tag attributes. >> >> Regarding event handling: >> >> The browser should not assign the link context URI to window.location >> / update history until the app has fully handled the navigation event. >> This would allow browsing contexts to internally cancel the event, for >> example if they determine that their state is saturated, and a new or >> alternate browsing context should handle the navigation instead. >> Events could be canceled via event.preventDefault(). One case in >> which navigation should not be cancelable is explicit window.location >> assignment, in which case the event’s “cancelable” property should be >> set to false. In order to stop event propagation to any further >> browsing contexts, event.stopPropagation() could be used. Since the >> new window.location will not be available during event handling, the >> event should include a “location” property containing the new URL. >> Also, suppose a user navigates from “example.com?x=1” to >> “example.com?y=2”. An app may wish to retain the “x=1” state, and >> instead navigate to “example.com?x=1&y=2”. This could be supported by >> making the event’s “location” property assignable. Event completion >> could be defined either in an implicit fashion, such as completion of >> all event handlers, or if necessary in an explicit fashion, such as >> setting an event “complete” property to true. >> >> Browsing contexts should not be required to have been initialized via >> the link relation to receive navigation events, browsing contexts >> having been initialized via traditional direct navigation to the link >> target resource should be eligible as well. This way link relation >> indirection can be avoided during initial navigations directly to the >> app root. Also, non window.location assignment triggered navigation >> events should be allowed to be sent to any existing matching browsing >> context, not just the browsing context in which the event originated >> (if any), or could ignore existing browsing contexts (as with “Open >> link in New Tab”). This would allow users to re-enter existing >> browsing contexts to merge with their existing state, or create new >> browsing contexts to obtain fresh state as desired. There should be a >> way to determine if the event originated in the browsing context >> itself, either by comparing the browsing context’s AbstractView >> (window object) to the event’s “view” property, or by adding an >> “internal” flag. >> >> Thanks, >> Sean Eagan >> >> >
Received on Wednesday, 29 June 2011 11:08:45 UTC