- From: Paul Kinlan <paulkinlan@google.com>
- Date: Wed, 7 Dec 2011 17:59:43 +0000
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
Received on Wednesday, 7 December 2011 09:59:43 UTC