- From: Paul Kinlan <paulkinlan@google.com>
- Date: Sat, 17 Dec 2011 15:08:05 +0000
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> > wrote: >> >> 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 use. > > 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[1] 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. > > >> [1] http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen > > > > -- > 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 Saturday, 17 December 2011 07:08:05 UTC