Re: Proposal: Navigation of JSON documents with html-renderer-script link relation

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