Re: [whatwg] Proposal: intent tag for Web Intents API
On 1/25/2012 5:06 PM, Paul Kinlan wrote: [Merging the digest reply from Charles] Thanks, sorry about breaking the subject line. For others: this mini thread is in relation to intentscript src=/script/intent behavior. I would prefer to treat it like a embedded content element [1] and have the intent spec define how fallback content should be presented and parsed - so we would define thatscript is ignored in a conforming UA. In our case we would want to work like the video element [2] with the added script restriction. Is this a completely abhorent solution? Yes, that's completely abhorrent. Remember, video uses new tags, like source, so it can get away with such trickery. script, like the img tag, is old magic. We would have to change the HTML parser or otherwise alter DOM semantics to make it work. Image content and script content in the dom, with a src attribute, will be loaded regardless of tags, with the exception of noscript. videoimg src=content.jpg //video -- that'll still load the image, though it won't display it. -Charles
Re: [whatwg] Proposal: intent tag for Web Intents API
Understood. The case still stands that we can use the intent tag in the body, have script fallback if the publisher decides to add the shim by way of adding the dom Element or just always including the proxy code - or just have a nice piece of text/dom for some other fallback mechanism of completing the action (such as a link to a scriptlet). We don't get this ability with the other methods discussed (meta - link). Note: I added a script element inside a video element and a supporting browser still executed the code. It is a shame because I think it is a nice solution (in theory). P On Wed, Jan 25, 2012 at 5:14 PM, Charles Pritchard ch...@jumis.com wrote: On 1/25/2012 5:06 PM, Paul Kinlan wrote: [Merging the digest reply from Charles] Thanks, sorry about breaking the subject line. For others: this mini thread is in relation to intentscript src=/script/intent behavior. I would prefer to treat it like a embedded content element [1] and have the intent spec define how fallback content should be presented and parsed - so we would define thatscript is ignored in a conforming UA. In our case we would want to work like the video element [2] with the added script restriction. Is this a completely abhorent solution? Yes, that's completely abhorrent. Remember, video uses new tags, like source, so it can get away with such trickery. script, like the img tag, is old magic. We would have to change the HTML parser or otherwise alter DOM semantics to make it work. Image content and script content in the dom, with a src attribute, will be loaded regardless of tags, with the exception of noscript. videoimg src=content.jpg //video -- that'll still load the image, though it won't display it. -Charles -- 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
Re: [whatwg] Proposal: intent tag for Web Intents API
On Fri, 16 Dec 2011 20:35:22 +0100, Paul Kinlan paulkin...@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. 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. 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. [1] http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: intent tag for Web Intents API
On Sat, Dec 17, 2011 at 1:29 PM, Anne van Kesteren ann...@opera.com wrote: On Fri, 16 Dec 2011 20:35:22 +0100, Paul Kinlan paulkin...@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
Re: [whatwg] Proposal: intent tag for Web Intents API
On Wed, 14 Dec 2011 23:05:37 +0100, Greg Billock gbill...@google.com wrote: The big ergonomic sticking point there is probably the |href| attribute, which we envision being able to do same-origin registration. Perhaps a similar link rel=intent tag modification would be able to do that, though. Is that what you'd suggest? Do you think having two tags involved would be confusing? If there's always an href attribute you could just go for link instead. I think you should go for one element and just add attributes as required. And if we want to put inside head that would be either meta or link. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: intent tag for Web Intents API
On 2011-12-08 18:54, Anne van Kesteren wrote: On Wed, 07 Dec 2011 18:59:43 +0100, Paul Kinlan paulkin...@google.com wrote: 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) We can just add additional attributes to meta you know. We have done the same for link. E.g. for link rel=icon you can specify a sizes attribute. Hmmm. That makes it sound a lot easier than it is. After all, there's no extension point here. Adding attributes to meta (or link) requires a change to HTML5, or a delta spec adding these as conforming attributes. Best regards, Julian
Re: [whatwg] Proposal: intent tag for Web Intents API
There isn't always a href, if left out the value action should be launched on the current page. 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-. 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. 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. [1] http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen P On Fri, Dec 16, 2011 at 9:54 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Dec 2011 23:05:37 +0100, Greg Billock gbill...@google.com wrote: The big ergonomic sticking point there is probably the |href| attribute, which we envision being able to do same-origin registration. Perhaps a similar link rel=intent tag modification would be able to do that, though. Is that what you'd suggest? Do you think having two tags involved would be confusing? If there's always an href attribute you could just go for link instead. I think you should go for one element and just add attributes as required. And if we want to put inside head that would be either meta or link. -- 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
Re: [whatwg] Proposal: intent tag for Web Intents API
I know James mentioned [1] that we are leaning towards having the tag in the body which opens up the possibility of unsuported browsers showing the content of the element. This had some general consensus [2] [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034084.html [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034087.html On Fri, Dec 16, 2011 at 9:44 PM, Adam Barth w...@adambarth.com wrote: On Fri, Dec 16, 2011 at 11:35 AM, Paul Kinlan paulkin...@google.com wrote: There isn't always a href, if left out the value action should be launched on the current page. 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-. 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. 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. Does that mean you're not interested in declaring this information in the head ? Adam [1] http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen P On Fri, Dec 16, 2011 at 9:54 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Dec 2011 23:05:37 +0100, Greg Billock gbill...@google.com wrote: The big ergonomic sticking point there is probably the |href| attribute, which we envision being able to do same-origin registration. Perhaps a similar link rel=intent tag modification would be able to do that, though. Is that what you'd suggest? Do you think having two tags involved would be confusing? If there's always an href attribute you could just go for link instead. I think you should go for one element and just add attributes as required. And if we want to put inside head that would be either meta or link. -- 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 -- 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
Re: [whatwg] Proposal: intent tag for Web Intents API
To be clear, you're ok with not being able to include the intent element in the head. Adam On Fri, Dec 16, 2011 at 2:13 PM, Paul Kinlan paulkin...@google.com wrote: I know James mentioned [1] that we are leaning towards having the tag in the body which opens up the possibility of unsuported browsers showing the content of the element. This had some general consensus [2] [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034084.html [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034087.html On Fri, Dec 16, 2011 at 9:44 PM, Adam Barth w...@adambarth.com wrote: On Fri, Dec 16, 2011 at 11:35 AM, Paul Kinlan paulkin...@google.com wrote: There isn't always a href, if left out the value action should be launched on the current page. 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-. 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. 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. Does that mean you're not interested in declaring this information in the head ? Adam [1] http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen P On Fri, Dec 16, 2011 at 9:54 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Dec 2011 23:05:37 +0100, Greg Billock gbill...@google.com wrote: The big ergonomic sticking point there is probably the |href| attribute, which we envision being able to do same-origin registration. Perhaps a similar link rel=intent tag modification would be able to do that, though. Is that what you'd suggest? Do you think having two tags involved would be confusing? If there's always an href attribute you could just go for link instead. I think you should go for one element and just add attributes as required. And if we want to put inside head that would be either meta or link. -- 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 -- 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
Re: [whatwg] Proposal: intent tag for Web Intents API
Simon Pieters wrote: I'm not sure it's a good idea security-wise to have this feature as an element. Many sites use black-list based HTML filtering of user input, to filter out bad stuff like script elements. It's easy to argue that they are already screwed, but we still have to think about it when adding new features to the platform, because there are many such sites. It would be easy to inject an intent tag to such sites, whereas it is harder to call navigator.register*Handler. It's true that if a site is relying on tag stripping, it might be easier to inject an intent tag than raw script content. (On the other hand, it seems that such a site is likely to have other vulnerabilities...) But there's still another big hurdle between that injection and an attack. (The user must approve the registration, then perform an action which launches the intent, then select the service, but let's say those are much smaller hurdles.) Even with malicious content chosen by the attacker, the only impact on the target page is injecting a window.intent object with some opaque (but malicious!) content. Getting the page to execute that malicious content is the big hurdle. Either you can inject code into the page causing this execution, in which case, why bother, or the page is using window.intent unsafely. This is a concern, but in that case, the exploit is more easily accomplished directly, rather than a circuitous route through an injected intent tag. Another threat model related to this is cross-origin registration. If an intent tag can be injected with a cross-origin service, information about the current page state could be leaked to the malicious host by way of that cross-origin url. If the site is relying on a blacklist (so, say, img tags couldn't be injected), and has a vulnerability allowing the gathering of information on the page or the DOM context, then an intent tag injection is a new vehicle to carry that data to an attacker. Again, there's a couple more obstacles: the user would need to approve the registration and then launch an intent, but those sound easy to arrange. The real way to combat this is to not allow cross-origin service registration. Separately, I'm not so happy with having two APIs for the same thing. We don't enable anything new, but we double the attack surface, the cost to implement and test, authors need to not only learn both, but also need to learn (and argue) about which to use, and so forth. register*Handler has already been shipped in some browsers. We've seen some down-sides of the imperative registration approach: clients ask for ways to detect if they are registered, which breaks opacity and is, I think, a bigger security concern than the above. A declarative registration places the burden for maintaining that opacity on the user agent, which is a more appropriate place for such burdens. :-) -Greg Billock
Re: [whatwg] Proposal: intent tag for Web Intents API
Anne van Kesteren wrote: We can just add additional attributes to meta you know. We have done the same for link. E.g. for link rel=icon you can specify a sizes attribute. That sounds like an interesting option. So instead of having intent action=... type=... href=... title=... disposition=.../intent we'd have meta name=intent action=... type=... href=... title=... disposition=.../meta If we want alternate layout in the body, would we also need to change the requirement that meta have the |itemprop| attribute in that context? I do think this approach has much better developer ergonomics than a collection of tags like meta name=intent-action content=... meta name=intent-type content=... meta name=intent-disposition content=... The big ergonomic sticking point there is probably the |href| attribute, which we envision being able to do same-origin registration. Perhaps a similar link rel=intent tag modification would be able to do that, though. Is that what you'd suggest? Do you think having two tags involved would be confusing? -Greg Billock
Re: [whatwg] Proposal: intent tag for Web Intents API
On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 6 Dec 2011, James Hawkins wrote: One of the critical pieces of the API is a declarative registration which allows sites to declare which intents they may be registered for. The current draft of the API calls for a new HTML tag, intent, the attributes of which describe the service registration: [...] Separate from the issue of what precisely the element should look like, I wonder if you could expand on the precise use case for the element. In particular, I'm interested in whether this use case might also apply to some of the register*Handler() methods we have now. Ideally, it would be good to have the current protocol and content type handlers and the Web Intent stuff all use a coherent and consistent API. Absolutely, we're very keen on providing RPH/RCH functionality via Web Intents. Let me start with the use case for the intent element, then I'll get to R*H. *** Use cases *** The intent element serves as a declaration of functionality of a web app. For example, Twitter exposes share functionality, Picnik exposes editing functionality, Dropbox exposes pick/save functionality, etc. Once the user accepts these registrations (gives permission), the UA can connect a client requesting a given set of functionality to the service that previously exposed that functionality. The fact that the element is declarative is a win wrt sites that may wish to crawl the web to index which web app handles which functionality. See www.openintents.org/en/intentstable for an example of this for Android Intents. *** RPH/RCH *** registerProtocolHandler gives services a way to imperatively expose functionality that is to specific to protocols. Web Intents will handle this use case by adding a scheme/URL pattern attribute to the intent registration. Android Intents exposes scheme/URL pattern filtering as well, so this addition moves Web Intents that much closer to its model API. navigator.registerProtocolHandler(mailto, https://www.example.com/?uri=%s;, Mail Service); becomes intent scheme=mailto title=Mail Service Click here to install our Mail Service application! /intent registerContentHandler allows services to imperatively expose functionality that is specific to content types. Web Intents will provide this use case by special-casing the intent element when no action is provided for a particular MIME type. navigator.registerContentHandler(image/png, http://www.example.com/?foo=%s;, My Image Viewer); becomes intent type=image/png title=My Image Viewer Click here to install our Image Viewer application! /intent Of course the fallback content is optional and determined by the service, but we believe it's a great way to expose fallback functionality via installable extensions/apps/whatnot. *** Advantages *** Client-side handling. For R*H, ?foo=%s normally requires server side processing. With Web Intents, this data is passed completely client-side on the intent object. Wildcard matching. R*H does not allow wildcard matching, where as Web Intents would allow a service to register for image/* in one succinct registration. Thanks, James
Re: [whatwg] Proposal: intent tag for Web Intents API
On Mon, 12 Dec 2011 20:59:36 +0100, James Hawkins jhawk...@google.com wrote: On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 6 Dec 2011, James Hawkins wrote: One of the critical pieces of the API is a declarative registration which allows sites to declare which intents they may be registered for. The current draft of the API calls for a new HTML tag, intent, the attributes of which describe the service registration: [...] Separate from the issue of what precisely the element should look like, I wonder if you could expand on the precise use case for the element. In particular, I'm interested in whether this use case might also apply to some of the register*Handler() methods we have now. Ideally, it would be good to have the current protocol and content type handlers and the Web Intent stuff all use a coherent and consistent API. Absolutely, we're very keen on providing RPH/RCH functionality via Web Intents. Let me start with the use case for the intent element, then I'll get to R*H. *** Use cases *** The intent element serves as a declaration of functionality of a web app. For example, Twitter exposes share functionality, Picnik exposes editing functionality, Dropbox exposes pick/save functionality, etc. Once the user accepts these registrations (gives permission), the UA can connect a client requesting a given set of functionality to the service that previously exposed that functionality. The fact that the element is declarative is a win wrt sites that may wish to crawl the web to index which web app handles which functionality. See www.openintents.org/en/intentstable for an example of this for Android Intents. *** RPH/RCH *** registerProtocolHandler gives services a way to imperatively expose functionality that is to specific to protocols. Web Intents will handle this use case by adding a scheme/URL pattern attribute to the intent registration. Android Intents exposes scheme/URL pattern filtering as well, so this addition moves Web Intents that much closer to its model API. navigator.registerProtocolHandler(mailto, https://www.example.com/?uri=%s;, Mail Service); becomes intent scheme=mailto title=Mail Service Click here to install our Mail Service application! /intent I'm not sure it's a good idea security-wise to have this feature as an element. Many sites use black-list based HTML filtering of user input, to filter out bad stuff like script elements. It's easy to argue that they are already screwed, but we still have to think about it when adding new features to the platform, because there are many such sites. It would be easy to inject an intent tag to such sites, whereas it is harder to call navigator.register*Handler. Separately, I'm not so happy with having two APIs for the same thing. We don't enable anything new, but we double the attack surface, the cost to implement and test, authors need to not only learn both, but also need to learn (and argue) about which to use, and so forth. register*Handler has already been shipped in some browsers. registerContentHandler allows services to imperatively expose functionality that is specific to content types. Web Intents will provide this use case by special-casing the intent element when no action is provided for a particular MIME type. navigator.registerContentHandler(image/png, http://www.example.com/?foo=%s;, My Image Viewer); becomes intent type=image/png title=My Image Viewer Click here to install our Image Viewer application! /intent Of course the fallback content is optional and determined by the service, but we believe it's a great way to expose fallback functionality via installable extensions/apps/whatnot. The fallback would be more like Your browser doesn't support the intent tag, no? *** Advantages *** Client-side handling. For R*H, ?foo=%s normally requires server side processing. With Web Intents, this data is passed completely client-side on the intent object. Wildcard matching. R*H does not allow wildcard matching, where as Web Intents would allow a service to register for image/* in one succinct registration. I guess these features could be added to register*Handler without adding a new element to register handlers. Thanks, James -- Simon Pieters Opera Software
Re: [whatwg] Proposal: intent tag for Web Intents API
On Wed, 07 Dec 2011 18:59:43 +0100, Paul Kinlan paulkin...@google.com wrote: 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) We can just add additional attributes to meta you know. We have done the same for link. E.g. for link rel=icon you can specify a sizes attribute. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, 6 Dec 2011, James Hawkins wrote: One of the critical pieces of the API is a declarative registration which allows sites to declare which intents they may be registered for. The current draft of the API calls for a new HTML tag, intent, the attributes of which describe the service registration: [...] Separate from the issue of what precisely the element should look like, I wonder if you could expand on the precise use case for the element. In particular, I'm interested in whether this use case might also apply to some of the register*Handler() methods we have now. Ideally, it would be good to have the current protocol and content type handlers and the Web Intent stuff all use a coherent and consistent API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: intent tag for Web Intents API
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 ann...@opera.com wrote: On Tue, 06 Dec 2011 19:40:20 +0100, Paul Kinlan paulkin...@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
[whatwg] Proposal: intent tag for Web Intents API
*** Overview ***
The W3C Web Intents Task Force is working on the Web Intents API at
public-web-inte...@w3.org: see the bottom of this email for details.
Web Intents is a web platform API that provides client-side service
discovery and inter-application communication. Services register to
handle high-level actions (e.g., share, edit, pick), while clients
invoke an intent (action + type + data). For example twitter.com may
allow the user to register the site as a provider of the 'share'
action.
One of the critical pieces of the API is a declarative registration
which allows sites to declare which intents they may be registered
for. The current draft of the API calls for a new HTML tag, intent,
the attributes of which describe the service registration:
!ENTITY % Disposition {window|inline}
!ELEMENT INTENT - O EMPTY -- a Web Intents registration -
!ATTLIST INTENT
action %URI; #REQUIRED -- URI specifying action --
type%ContentTypes; #IMPLIED -- advisory content types --
href%URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition window-- where the service is created --
We settled on the intent tag after reviewing several alternatives
(see below). The intent tag offers the greatest ease-of-use for
developers, and the ability to crawl/index sites that support Intents.
One of the cool things about the declarative syntax is that it allows
one to create sites (like http://www.openintents.org/en/intentstable)
which serve as a database of services that support intents. We're
currently adding a section on webintents.org that allows the developer
of a service to be add his service to the registry by entering the
service URL, which we then crawl and index the intents.
One could also imagine exposing intent services using search engine technology.
*** Proposal ***
Add the intent tag to the HTML spec.
*** Alternatives ***
Imperative DOM registration: registerIntentHandler(...).
Pros:
* Analogous to registerProtocolHandler, registerContentHandler.
* Doesn't require addition to the HTML spec.
Cons:
* Not declarative, not as easy to index.
* Timing requirements unclear (Is the registration removed if a
service does not call registerIntentHandler() on the next visit? If so
how long does the UA need to wait to 'be sure'?)
* Heavier footprint in the DOM API.
* Less self-documenting code:
registerIntentHandler('webintents.org/share',
'text/uri-list',
'handler.html',
'My Sharer',
'inline');
intent action=webintents.org
type=text/uri-list
href=handler.html
title=My Sharer
disposition=inline
/intent
link rel=intents:
Pros:
* Declarative.
Cons:
* link rel has become a dumping ground for these type of usages.
* Need to modify HTML spec to add appropriate attributes.
CRX-less Web Apps
(http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html):
Pros:
* Declarative.
Cons:
* Not standardized.
* Requires extra level of indirection.
*** API Status ***
Within the W3C the Webapps WG is rechartering to include Web Intents
as a joint-deliverable with the DAP WG (which already had Intents in
its charter). Discussion is taking place about the API at
public-web-inte...@w3.org.
The draft API is current hosted at [1], though I'm working feverishly
to convert this into a W3C-style draft format.
[1]
https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi
Our use cases, JavaScript shim, and example pages are hosted at
http://webintents.org.
Thanks,
James Hawkins
Re: [whatwg] Proposal: intent tag for Web Intents API
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.
On Tue, Dec 6, 2011 at 6:00 PM, James Hawkins jhawk...@google.com wrote:
*** Overview ***
The W3C Web Intents Task Force is working on the Web Intents API at
public-web-inte...@w3.org: see the bottom of this email for details.
Web Intents is a web platform API that provides client-side service
discovery and inter-application communication. Services register to
handle high-level actions (e.g., share, edit, pick), while clients
invoke an intent (action + type + data). For example twitter.com may
allow the user to register the site as a provider of the 'share'
action.
One of the critical pieces of the API is a declarative registration
which allows sites to declare which intents they may be registered
for. The current draft of the API calls for a new HTML tag, intent,
the attributes of which describe the service registration:
!ENTITY % Disposition {window|inline}
!ELEMENT INTENT - O EMPTY -- a Web Intents registration -
!ATTLIST INTENT
action %URI; #REQUIRED -- URI specifying action --
type %ContentTypes; #IMPLIED -- advisory content types --
href %URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition window -- where the service is created --
We settled on the intent tag after reviewing several alternatives
(see below). The intent tag offers the greatest ease-of-use for
developers, and the ability to crawl/index sites that support Intents.
One of the cool things about the declarative syntax is that it allows
one to create sites (like http://www.openintents.org/en/intentstable)
which serve as a database of services that support intents. We're
currently adding a section on webintents.org that allows the developer
of a service to be add his service to the registry by entering the
service URL, which we then crawl and index the intents.
One could also imagine exposing intent services using search engine
technology.
*** Proposal ***
Add the intent tag to the HTML spec.
*** Alternatives ***
Imperative DOM registration: registerIntentHandler(...).
Pros:
* Analogous to registerProtocolHandler, registerContentHandler.
* Doesn't require addition to the HTML spec.
Cons:
* Not declarative, not as easy to index.
* Timing requirements unclear (Is the registration removed if a
service does not call registerIntentHandler() on the next visit? If so
how long does the UA need to wait to 'be sure'?)
* Heavier footprint in the DOM API.
* Less self-documenting code:
registerIntentHandler('webintents.org/share',
'text/uri-list',
'handler.html',
'My Sharer',
'inline');
intent action=webintents.org
type=text/uri-list
href=handler.html
title=My Sharer
disposition=inline
/intent
link rel=intents:
Pros:
* Declarative.
Cons:
* link rel has become a dumping ground for these type of usages.
* Need to modify HTML spec to add appropriate attributes.
CRX-less Web Apps
(http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html):
Pros:
* Declarative.
Cons:
* Not standardized.
* Requires extra level of indirection.
*** API Status ***
Within the W3C the Webapps WG is rechartering to include Web Intents
as a joint-deliverable with the DAP WG (which already had Intents in
its charter). Discussion is taking place about the API at
public-web-inte...@w3.org.
The draft API is current hosted at [1], though I'm working feverishly
to convert this into a W3C-style draft format.
[1]
https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi
Our use cases, JavaScript shim, and example pages are hosted at
http://webintents.org.
Thanks,
James Hawkins
--
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
Re: [whatwg] Proposal: intent tag for Web Intents API
To clarify, my use of the word 'we' below is we the designers of the
API, not the participants of the Web Intents TF.
As stated in the 'API Status' section below, discussions about Web
Intents are ongoing in the TF. In addition, note that nothing is
finalized in the Web Intents API as of yet.
Since the registration aspect of the current draft of the API requires
the addition of a new tag, I decided to hold that discussion on the
appropriate ML, namely this ML.
Thanks,
James
On Tue, Dec 6, 2011 at 10:00 AM, James Hawkins jhawk...@google.com wrote:
*** Overview ***
The W3C Web Intents Task Force is working on the Web Intents API at
public-web-inte...@w3.org: see the bottom of this email for details.
Web Intents is a web platform API that provides client-side service
discovery and inter-application communication. Services register to
handle high-level actions (e.g., share, edit, pick), while clients
invoke an intent (action + type + data). For example twitter.com may
allow the user to register the site as a provider of the 'share'
action.
One of the critical pieces of the API is a declarative registration
which allows sites to declare which intents they may be registered
for. The current draft of the API calls for a new HTML tag, intent,
the attributes of which describe the service registration:
!ENTITY % Disposition {window|inline}
!ELEMENT INTENT - O EMPTY -- a Web Intents registration -
!ATTLIST INTENT
action %URI; #REQUIRED -- URI specifying action --
type %ContentTypes; #IMPLIED -- advisory content types --
href %URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition window -- where the service is created --
We settled on the intent tag after reviewing several alternatives
(see below). The intent tag offers the greatest ease-of-use for
developers, and the ability to crawl/index sites that support Intents.
One of the cool things about the declarative syntax is that it allows
one to create sites (like http://www.openintents.org/en/intentstable)
which serve as a database of services that support intents. We're
currently adding a section on webintents.org that allows the developer
of a service to be add his service to the registry by entering the
service URL, which we then crawl and index the intents.
One could also imagine exposing intent services using search engine
technology.
*** Proposal ***
Add the intent tag to the HTML spec.
*** Alternatives ***
Imperative DOM registration: registerIntentHandler(...).
Pros:
* Analogous to registerProtocolHandler, registerContentHandler.
* Doesn't require addition to the HTML spec.
Cons:
* Not declarative, not as easy to index.
* Timing requirements unclear (Is the registration removed if a
service does not call registerIntentHandler() on the next visit? If so
how long does the UA need to wait to 'be sure'?)
* Heavier footprint in the DOM API.
* Less self-documenting code:
registerIntentHandler('webintents.org/share',
'text/uri-list',
'handler.html',
'My Sharer',
'inline');
intent action=webintents.org
type=text/uri-list
href=handler.html
title=My Sharer
disposition=inline
/intent
link rel=intents:
Pros:
* Declarative.
Cons:
* link rel has become a dumping ground for these type of usages.
* Need to modify HTML spec to add appropriate attributes.
CRX-less Web Apps
(http://code.google.com/intl/en-US/chrome/apps/docs/no_crx.html):
Pros:
* Declarative.
Cons:
* Not standardized.
* Requires extra level of indirection.
*** API Status ***
Within the W3C the Webapps WG is rechartering to include Web Intents
as a joint-deliverable with the DAP WG (which already had Intents in
its charter). Discussion is taking place about the API at
public-web-inte...@w3.org.
The draft API is current hosted at [1], though I'm working feverishly
to convert this into a W3C-style draft format.
[1]
https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi
Our use cases, JavaScript shim, and example pages are hosted at
http://webintents.org.
Thanks,
James Hawkins
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, 06 Dec 2011 19:40:20 +0100, Paul Kinlan paulkin...@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/
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, 06 Dec 2011 19:00:36 +0100, James Hawkins jhawk...@google.com
wrote:
!ENTITY % Disposition {window|inline}
!ELEMENT INTENT - O EMPTY -- a Web Intents registration -
!ATTLIST INTENT
action %URI; #REQUIRED -- URI specifying action --
type%ContentTypes; #IMPLIED -- advisory content types --
href%URI; #IMPLIED -- URI for linked resource --
title %i18n; #IMPLIED -- service title --
disposition %Disposition window-- where the service is created --
Off-topic, but I'm curious as to why you decided to propose a new element
this way?
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, 6 Dec 2011, Anne van Kesteren wrote: 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. Yes, I consider adding new elements to head to be very very bad for this reason. Breaking DOM consistency between supporting and non-supporting browsers can cause adding an intent to cause unrelated breakage (e.g. by changing document.body.firstChild).
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, Dec 6, 2011 at 1:08 PM, James Graham jgra...@opera.com wrote: On Tue, 6 Dec 2011, Anne van Kesteren wrote: 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. Yes, I consider adding new elements to head to be very very bad for this reason. Breaking DOM consistency between supporting and non-supporting browsers can cause adding an intent to cause unrelated breakage (e.g. by changing document.body.firstChild). Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? James
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, Dec 6, 2011 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Dec 6, 2011 at 1:14 PM, James Hawkins jhawk...@google.com wrote: Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? So, when the intent tag is supported, it's not displayed at all, and instead solely handled by the browser? This seems okay to me. Correct.
Re: [whatwg] Proposal: intent tag for Web Intents API
On Tue, 6 Dec 2011, James Hawkins wrote: On Tue, Dec 6, 2011 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Dec 6, 2011 at 1:14 PM, James Hawkins jhawk...@google.com wrote: Originally we envisioned using a self-closing tag placed in head for the intent tag; however, we're now leaning towards not using self-closing and having the tag be placed in the body with fallback content, e.g., to install an extension to provide similar functionality. intent action=webintents.org/share Click here to install our extension that implements sharing! /intent What are your thoughts on this route? So, when the intent tag is supported, it's not displayed at all, and instead solely handled by the browser? This seems okay to me. Correct. This seems to remove my major objection to the new tag design.
