[whatwg] Proposal: <intent> tag for Web Intents API
paulkinlan at google.com
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/*">
* use's existing tags so no changes to html spec
* 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
* 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>
>> 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/*" />
>> * declarative
>> * use's existing tags so no changes to html spec
>> * 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
Developer Advocate @ Google for Chrome and HTML5
More information about the whatwg