- From: Greg Billock <gbillock@google.com>
- Date: Thu, 24 May 2012 15:55:59 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org
On Fri, Apr 20, 2012 at 10:35 AM, Greg Billock <gbillock@google.com> wrote: > Ian, > > >> My suggestion then would be to add an element similar to what you suggest, >> as well as an API similar to the existing one. >> >> The element could be something like: >> >> <intent >> action="edit" intent action, e.g. open or edit, default "share" >> type="image/png" MIME type filter [1], default "*/*" >> scheme="mailto" Scheme filter [1] [2], default omitted >> href="" Handler URL [2], default "" >> title="Foo" Handler user-visible name, required attribute >> disposition="" "replace", "new", or "overlay", default "overlay" >> ></intent> >> >> [1] Only one of type="" and scheme="" is allowed. >> [2] scheme="" is only allowed if href="" contains %s. >> >> The API could be something like: >> >> void registerIntentHandler(DOMString action, DOMString type, DOMString url, DOMString title, DOMString disposition); >> DOMString isIntentHandlerRegistered(DOMString action, DOMString type, DOMString url); >> void unregisterIntentHandler(DOMString action, DOMString type, DOMString url); >> >> The disposition of registerContentHandler() and registerProtocolHandler() >> would always be "replace". The /url/ argument of registerProtocolHandler() >> would not be allowed to contain %s. Here's a slightly altered suggestion. There'd be three imperative registration APIs and three permissible intent tag configurations: For web intents services: <intent action=a type=t href=u ...> (that is, both action and type required, scheme disallowed) void registerIntentHandler(a, t, u, ...); // and unregister for protocol handler services: <intent scheme=s href=u ...> (scheme required, action and type disallowed) void registerProtocolHandler(s, u, ...); // and unregister for content handler services: <intent type=t href=u ...> (type required, action and scheme disallowed) void registerContentHandler(t, u, ...); // and unregister intent tags without these permissible permutations of scheme|action|type attributes must be ignored. Some more concordance moves to make them more like different aspects of the same feature: * In registerContentHandler, "t" can be a space-separated list of MIME types for registerContentHandler. * Let's think through why we'd need to limit the dispositions of the case of RPH/RCH to disposition="replace". Can't we achieve backwards compatibility by specifying that those cases default to disposition=replace? This would make it straightforward to get a nice style of navigational interaction with web intents -- RPH-style invocations can be handled by any of the disposition transitions. (i.e. a "mailto" handler that did all it's work in an overlay, which is frequently very desirable). * Add a couple more legal permutations: adding 'action="view"' to the RPH/RCH registration intent tags would mean that the payload gets delivered using web intents instead of through %s-substitution. The RPH/RCH APIs wouldn't expose this. (This is very useful for offline.) These aren't large modifications, and in general just increase "forward compatibility" by making it more clear how to get more functionality out of RPH/RCH by using declarative registration, and blending those cases into the intents-based implementation. -Greg
Received on Thursday, 24 May 2012 22:56:30 UTC