- From: Paul Kinlan <paulkinlan@google.com>
- Date: Thu, 19 Jan 2012 13:51:02 -0800
- To: Mike Kelly <mikekelly321@gmail.com>
- Cc: James Hawkins <jhawkins@chromium.org>, public-web-intents@w3.org
CIL. On Thu, Jan 19, 2012 at 12:56 PM, Mike Kelly <mikekelly321@gmail.com> wrote: > > > On Thu, Jan 19, 2012 at 5:15 PM, Paul Kinlan <paulkinlan@google.com> wrote: >> >> On Thu, Jan 19, 2012 at 8:54 AM, Mike Kelly <mikekelly321@gmail.com> >> wrote: >> > >> > >> > On Thu, Jan 19, 2012 at 4:34 PM, James Hawkins <jhawkins@chromium.org> >> > wrote: >> >> >> >> There are a few drawbacks with using the link element. >> >> * link must appear in the head and is a void element. >> >> - This prevents the use case of the service site providing >> >> alternative >> >> UI if <intent> is not supported: <intent ...>Intents are not supported! >> >> Check out this work-around</intent> >> > >> > >> > Both of these issues are worth exploring with html5 working group, more >> > than >> > happy to get involved on this. >> > >> >> >> >> * In the current syntax you provided, how would the UA know this is an >> >> intent registration? Per the spec, |action| is just a string; we use >> >> URLs >> >> to set precedence as a developer-friendly way of documenting the >> >> action. >> > >> > >> > Presumably UAs only react to the @action tokens they understand? Using >> > link >> > will provide them with a slightly larger set of elements to go through >> > to >> > find these, which should not present an issue - am I missing something >> > here? >> >> An intent action string can be any string - it is simply a token that >> the client and service agree to use to discover each other and have an >> accepted basic protocol for data exchange - an enterprise application >> that never sees the light of day on the open internet could define >> "fluffykittens" as an action name (although that would be a terrible >> name) and as long as their client and service applications used >> fluffykittens they would be able to discover each other. > > > Yep absolutely, this is exactly how link relations work too. The question is what do we do in the case where the action verb is the same as a rel name "author" for instance, there is no way to know that the definition in the "rel" is an intent or not. > >> >> >> > >> >> >> >> * We'd have to change the HTML parsing algorithm. >> >> >> > >> > I'm not au fait with the implementation here, is this a significant >> > undertaking? >> > >> >> >> >> Can you share your objections to using the <intent> element? >> > >> > >> > It is, ostensibly, a link.. so why not expose it as one? There is a lot >> > of >> > existing web infrastructure that is already geared up to work with >> > links. >> > e.g. atom has a link element, we have the Link header in HTTP, and links >> > and >> > relations are already familiar to developers. >> > >> > Linking is a very 'web' thing, so re-using <link> would make web intents >> > 'fit in' better with the rest of the web. >> >> It doesn't have to be a link, absence of a link infers the current >> page. > > > href is not a required property of <link> in HTML, so this is not an issue. > >> >> Added to this, the remote page has no need to be fetched which >> the <link> element is meant to acheive, i.e, this page enhances the >> current page - the intent href semantically doesn't mean this. > > > I'm not sure what you mean - I think this is a distinction you are drawing > yourself rather than one that is specified anywhere? Is there something in > the html spec you are basing this on? http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#introduction-3 and http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element "The destination of the link(s) is given by the href attribute, which must be present and must contain a valid non-empty URL potentially surrounded by spaces. If the href attribute is absent, then the element does not define a link." This is the whatwg definition but it is the same on the w3c site. P > > Cheers, > Mike -- 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 Thursday, 19 January 2012 21:51:31 UTC