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

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 Friday, 18 February 2011 17:03:45 UTC