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

Wed Dec 7 09:59:43 PST 2011

Sorry for not including the other meta syntax.

<meta name="intent" content="http://webintents.org/share image/*">

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

Cons:
* ordering of data in the content element - if the ordering of data in
the content value is mandatory and the developer mixes up the
ordering, does the action then become "image/png" (which is still
techincally valid) and the data type become the uri string specified?
* we have other optional attributes, such as title, disposition and
icon so a scheme needs to be defined inside the content, if we define
a scheme it looks similar to the intent tag but harder to prepare
(from a normal developers perspective)
* some attributes can have spaces so we would need to define encoding
mechanisms inside the content attribute to handle quotes, and double
quotes.
* we can't provide a visual fallback if intents aren't supported - see
discussion about self closing tag in body.
* harder to validate (due to all of the above)

On Tue, Dec 6, 2011 at 8:25 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 06 Dec 2011 19:40:20 +0100, Paul Kinlan <paulkinlan at google.com>
> wrote:
>>
>> 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.
>
>
> You could also have
>
> <meta name="intent" content="http://webintents.org/share image/*">
>
> or some such. Splitting a string on spaces and using the result is not that
> hard and a common pattern. And seems like a much better alternative than
> changing the HTML parser. Especially changing the way <head> is parsed is
> hairy. Every new element we introduce there will cause a <body> to be
> implied before it in down-level clients. That's very problematic.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/

-- 
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