WebIntents/Ian Hickson's Web Intent Proposal

From W3C Wiki

Intent names are simple strings, not URLs. It's what we use on the Web for pretty much everything: rel="", element names, MIME types, schemes, HTTP verbs, <meta> names, HTTP headers, pretty much everything.

  • invoking an intent:
  var port = navigator.handleIntent(intent, filter);

  port.start = function () { };
  port.onmessage = function (event) { handle(event.data) }; 
  port.close = function (event) { /* tidy up */ }; 

  // send some data
  port.postMessage(data);

Where the data would be a URL or JSON object. The port would close when the window closes.

  • to register:
  navigator.registerIntentHandler(intent, filter, url, kind);
    intent = string like "share", "play"
    filter = MIME type (foo/bar) or MIME wildcard (foo/* or */*)
    url = page to load to handle intent
    kind = a flag indicating if the page should be:
      - always opened in a new tab
      - opened in the intent handler dialog (inline/pop-up)
      - opened in an existing tab if possible, else a new tab
  • to check if registered, to unregister:
  navigator.isIntentHandlerRegistered(intent, filter, url);
  navigator.unregisterIntentandler(intent, filter, url);
  • to handle an intent:
  body.onintent = function (event) {
    // Check event.origin if you want to be origin-limited.
    // We could add event.intent and event.filter, for processors that
    // support many intents.
    var port = event.ports[0];
    var response = process(event.data);
    port.postMessage(response);
  };

In simple cases, the above can be even further simplified. For example, if you don't care about the response (e.g. for a share intent), and you don't have a filter type (so it'll only match */* filters):

  navigator.handleIntent('share').postMessage(data);

Similarly, handling an intent can be even easier than the above for simple cases. For example, in the share case again, where you don't send anything back but just share whatever is passed in:

  <body onintent="share(event.data)">

Note: the call to handleIntent shouldn't block the UI thread! This call will typically result in a dialog being presented to ask the user to select a service. An alternative API design would take a function as an argument to handleIntent, where the function is called when the intent has been bound. A further such argument could be used for handling error conditions, e.g. where the user didn't select a service, perhaps because no service matching the intent was available.