- From: Kris Zyp <kris@sitepen.com>
- Date: Wed, 11 May 2011 08:46:34 -0600
- To: public-webapps@w3.org
- CC: Sean Eagan <seaneagan1@gmail.com>
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, 11 May 2011 14:47:06 UTC