[whatwg] Proposal: <intent> tag for Web Intents API
paulkinlan at google.com
Sat Dec 17 07:08:05 PST 2011
On Sat, Dec 17, 2011 at 1:29 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Fri, 16 Dec 2011 20:35:22 +0100, Paul Kinlan <paulkinlan at google.com>
>> We didn't want to add additional attributes to the meta tag or link
>> tag just for intents, this seems to open up the flood gates for future
>> platform features to also extend the meta syntax, the meta element
>> then just becomes a dumping ground. If the answer when defining a new
>> declarative standardized platform feature is to just arbitrarily add
>> new attributes to the meta data element we will get to a point where
>> either we have attributes that are used in multiple contexts or use
>> of basic attribute name spacing such as "intent-".
> The answer is that when you want to add something new to the <head> element,
> it makes sense to consider using <meta> and <link>, and that adding
> attributes to them is not a big deal, because it rarely happens that we do
> so. In the close to eight years the WHATWG has been working on HTML, we have
> added one new attribute, to <link>.
My understanding for the one attribute is that it is augmenting
something that has long been done on the web and thus a new element in
this case for favicon sizes defiantly didn't make sense given that
nearly every page has a defined icon.
Intents is a new platform feature and we would add 4 or more on the
meta tag just for this first version of intents, and then more again
when we add more features to the intent declaration system to handle
RPH and RPC. I don't think this is an acceptable solution just for
intents and why a new self contained tag is a better solution.
If adding a new element in to the head is un-acceptable, which a few
people have brought up, moving it to the body is a more broadly
accepted solution, which we have the ability to style and control if a
UA doesn't support the tag and offer a the user another solution to
> Your argument is similar to why some people think HTML should have
> namespaces. And it does not make much sense. I mean, we could have a million
> elements in theory and we might need to disambiguate them if we do, but in
> practice HTML aims to address the common use cases and can therefore do with
> a relatively concise vocabulary. That also allows it to be widely
> implemented by many user agents in the same way.
I am arguing against using namespaces because I think that is
somewhere we would get too if we just start adding attributes to the
meta tag, the more concise vocabulary is with the intent tag for
describing the functionality of an app.
Added, the meta element is about describing the current page (which an
intent tag might not do, it can reference an app in the authors
domain) and link is about describing external resource that augment
the current document, which again intents don't do (fetching the value
in the optional href has no real meaning for the current document).
>> Looking at the spec it appears there would still be a relatively
>> large change to the html5 spec to accomodate these new attributes and
>> conditional parsing guidelines.
> There will be a relatively large change (larger, as it more complex) if we
> add a new element too.
>> A new tag is simple, concise and encapsulates the features and
>> requirements of the new platform feature and gives us scope to iterate
>> for future versions without stepping on the toes of the other features
>> that might use the meta tag.
> You do not create a conflict by adding new attributes. That makes no sense.
My point was aimed at adding atributes for this feature on a meta
element will block the same attribute name being used for a different
platform feature also using the meta tag. We use disposition, icon,
title and potentially scheme and other attributes.
>>  http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen
> Anne van Kesteren
Developer Advocate @ Google for Chrome and HTML5
More information about the whatwg