[whatwg] Proposal: <intent> tag for Web Intents API

[Paul Kinlan]

I would like to add that we also had a long discussion about trying to
re-use the meta element for specifying intents.

The syntax was something like:
<meta name="intent-action" content="http://webintents.org/share" />
<meta name="intent-type" content="image/*" />

Pros:
* declarative
* use's existing tags so no changes to html spec

Cons:
* no multiplicity - can't define multiple intents on the page without
complex encoding in the content attribute
* programmatically adding an intent into a page is very hard because
there are two tags.  The UA can't decide when to throw up the prompt
to grant access to install the web app as an intent handler.

On Tue, Dec 6, 2011 at 6:00 PM, James Hawkins <jhawkins at google.com> wrote:
> *** Overview ***
>
> The W3C Web Intents Task Force is working on the Web Intents API at
> public-web-intents at w3.org: see the bottom of this email for details.
>
> Web Intents is a web platform API that provides client-side service
> discovery and inter-application communication.  Services register to
> handle high-level actions (e.g., share, edit, pick), while clients
> invoke an intent (action + type + data).  For example twitter.com may
> allow the user to register the site as a provider of the 'share'
> action.
>
> One of the critical pieces of the API is a declarative registration
> which allows sites to declare which intents they may be registered
> for.  The current draft of the API calls for a new HTML tag, <intent>,
> the attributes of which describe the service registration:
>
> <!ENTITY % Disposition "{window|inline}">
>
> <!ELEMENT INTENT - O EMPTY      -- a Web Intents registration ->
> <!ATTLIST INTENT
>  action      %URI;          #REQUIRED -- URI specifying action --
>  type        %ContentTypes; #IMPLIED  -- advisory content types --
>  href        %URI;          #IMPLIED  -- URI for linked resource --
>  title       %i18n;         #IMPLIED  -- service title --
>  disposition %Disposition   window    -- where the service is created --
>  >
>
> We settled on the <intent> tag after reviewing several alternatives
> (see below).  The <intent> tag offers the greatest ease-of-use for
> developers, and the ability to crawl/index sites that support Intents.
>
> One of the cool things about the declarative syntax is that it allows
> one to create sites (like http://www.openintents.org/en/intentstable)
> which serve as a database of services that support intents.  We're
> currently adding a section on webintents.org that allows the developer
> of a service to be add his service to the registry by entering the
> service URL, which we then crawl and index the intents.
>
> One could also imagine exposing intent services using search engine technology.
>
> *** Proposal ***
>
> Add the <intent> tag to the HTML spec.
>
> *** Alternatives ***
>
> Imperative DOM registration: registerIntentHandler(...).
> Pros:
>  * Analogous to registerProtocolHandler, registerContentHandler.
>  * Doesn't require addition to the HTML spec.
> Cons:
>  * Not declarative, not as easy to index.
>  * Timing requirements unclear (Is the registration removed if a
> service does not call registerIntentHandler() on the next visit? If so
> how long does the UA need to wait to 'be sure'?)
>  * Heavier footprint in the DOM API.
>  * Less self-documenting code:
>
> registerIntentHandler('webintents.org/share',
>                             'text/uri-list',
>                             'handler.html',
>                             'My Sharer',
>                             'inline');
>
> <intent action="webintents.org"
>         type="text/uri-list"
>         href="handler.html"
>         title="My Sharer"
>         disposition="inline">
> </intent>
>
> link rel="intents":
> Pros:
>  * Declarative.
> Cons:
>  * link rel has become a dumping ground for these type of usages.
>  * Need to modify HTML spec to add appropriate attributes.
>
> CRX-less Web Apps
> (http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html):
> Pros:
>  * Declarative.
> Cons:
>  * Not standardized.
>  * Requires extra level of indirection.
>
> *** API Status ***
>
> Within the W3C the Webapps WG is rechartering to include Web Intents
> as a joint-deliverable with the DAP WG (which already had Intents in
> its charter).  Discussion is taking place about the API at
> public-web-intents at w3.org.
>
> The draft API is current hosted at [1], though I'm working feverishly
> to convert this into a W3C-style draft format.
>
> [1] https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi
>
> Our use cases, JavaScript shim, and example pages are hosted at
> http://webintents.org.
>
> Thanks,
> James Hawkins



-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan