[whatwg] Proposal: 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, , the attributes of which describe the service registration: We settled on the tag after reviewing several alternatives (see below). The 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 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'); 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: 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 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, , > the attributes of which describe the service registration: > > > > > 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 tag after reviewing several alternatives > (see below). The 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 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'); > > type="text/uri-list" > href="handler.html" > title="My Sharer" > disposition="inline"> > > > 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: tag for Web Intents API
On Tue, Dec 6, 2011 at 1:08 PM, James Graham wrote: > On Tue, 6 Dec 2011, Anne van Kesteren wrote: > >> Especially changing the way is parsed is hairy. Every new element >> we introduce there will cause a to be implied before it in down-level >> clients. That's very problematic. > > > Yes, I consider adding new elements to 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. Click here to install our extension that implements sharing! What are your thoughts on this route? James
Re: [whatwg] Proposal: tag for Web Intents API
On Tue, Dec 6, 2011 at 1:16 PM, Tab Atkins Jr. wrote: > On Tue, Dec 6, 2011 at 1:14 PM, James Hawkins 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. >> >> >> Click here to install our extension that implements sharing! >> >> >> What are your thoughts on this route? > > So, when the 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: tag for Web Intents API
On Thu, Dec 8, 2011 at 12:43 PM, Ian Hickson 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, , 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 Click here to install our Mail Service application! 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 Click here to install our Image Viewer application! 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
[whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
We, the designers of the Web Intents draft API, have always seen Web Intents as a superset of the functionality provided by registerProtocolHandler (RPH) and registerContentHandler (RCH). To follow this to the logical conclusion, we should be able to provide functionally equivalent counterparts to RPH/RCH in Web Intents. This proposal provides a means of deprecating RPH/RCH, replacing this functionality with equivalent functionality from Web Intents. For reference RPH/RCH are documented at [1]. The current draft of the Web Intents API is at [2]. registerProtocolHandler === The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular schemes. void registerProtocolHandler(DOMString scheme, DOMString url, DOMString title); We propose the addition of a 'scheme' attribute to the Web Intents service registration to handle this use case. * |scheme| is the same as specified for RPH. * If |scheme| is specified, |action| *should* (must?) be ignored. Thus, with this proposal, when the user clicks a "mailto:"; link, the UA will internally create a new intent containing the scheme and the URL parameters as the data in the payload. This payload will be delivered to the service the user picks. Note we’re considering specifying the UA may optionally decode the parameters into the |extras| object. Given the following anchor on mypage.com: mailto:m...@mypage.com?bcc=supp...@mypage.com&subject=testing";> the UA will deliver the following payload to the selected service: { type: “text/plain”, scheme: “mailto”, data: “mailto:m...@mypage.com?bcc=supp...@mypage.com&subject=testing”, extras: { bcc: “supp...@mypage.com”, subject: “testing” } } Open question: should we use the same whitelist of schemes used by RPH? registerContentHandler === The registerContentHandler() method allows Web sites to register themselves as possible handlers for content in a particular MIME type. void registerContentHandler(DOMString mimeType, DOMString url, DOMString title); We propose modifying the relationship between the |action| and |type| attributes to specify that if |action| is not specified and |type| is specified, the action is implicitly 'view' and the service must be shown in the picker when the UA encounters content of matching MIME type. The above registration would register the service to handle content of MIME type "image/png". When the UA loads a resource of type "image/png", it sends the type and content to the service in the payload. { data: pngImageContent, type: “image/png” } isProtocolHandlerRegistered / isContentHandlerRegistered = There are serious fingerprinting issues with these methods, and when contemplating analogous methods for Web Intents, we thought long and hard about the fingerprinting issue. As spec'ed a site could call registerProtocolHandler('web+uniqueID', ...) where uniqueID is unique to a user. The site could then call isProtocolHandlerRegistered with that matching 'web+uniqueID' to verify who the user is. One of the use cases for these methods is to allow a client site the ability to show alternative UI for protocols/content that are not capable of being handled by any service. Web Intents also requires a solution for this use case, as showing an empty picker* is a non-starter. * The picker refers to the UI in the UA that shows registered services for a given intent, allowing the user to pick which service to activate. Instead of creating analogous functionality of these methods for Web Intents, we decided to tackle the problem state of an empty picker. The proposed solution is to allow a client site to suggest a service (URL) that is displayed by the UA in the picker. The |suggestedService| parameter is optional. startActivity(..., suggestedService); In addition declarative registration removes the need to fashion registration as: if (!isProtocolHandlerRegistered(x)) registerProtocolHandler(x); The work of maintaining that state is displaced to the UA. unregisterProtocolHandler / unregisterContentHandler === The analogous functionality for these methods in Web Intents already exists and is the same as the removal of any type of service: remove the declarative registration from the content, and the UA will unregister the service as a handler. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers [2] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html Thanks, James
Re: [whatwg] Web Intents with System-Wide Sharing Features
Definitely, though I'd limit it to a "MAY" recommendation. James On Mon, Feb 20, 2012 at 9:08 PM, Rodger Combs wrote: > Mac OSX 10.8 (Mountain Lion), along with most mobile operating systems, has a > system-wide sharing functionality. Could the Web Intents API add a "SHOULD" > or "MAY" clause for adding web intents to the system-wide "share sheet" or > similar functionality, rather than just on the web? It fits with a few other > parts of the HTML5 spec that move towards OS integration (e.g. notifications, > which would fit well with Android/iOS/OSX10.8's built-in notification > centers).
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
Thanks for your feedback, Bjartur. On Tue, Feb 21, 2012 at 9:30 AM, Bjartur Thorlacius wrote: > Þann mið 15.feb 2012 23:39, skrifaði James Hawkins: > > * If |scheme| is specified, |action| *should* (must?) be ignored. >> > Why would you forbid distinguishing between actions on URIs? Postal and > retrieval of mail, for example, are quite distinct actions. As are > modification and retrieval of documents. > I'm not sure if the proposal was explicit enough, but for the RPH-esque functionality in Web Intents, we activate WI in the same circumstances RPH is activated, which is when links are activated in a page. Can you elucidate how the scenarios you listed could be handled? Note these scenarios are above and beyond RPH, but we're not trying to make the API self-limiting. Thanks, James
Re: [whatwg] Proposal: Deprecate registerProtocolHandler/registerContentHandler via Web Intents
On Tue, Feb 21, 2012 at 11:31 AM, Bjartur Thorlacius wrote: > Þann þri 21.feb 2012 18:44, skrifaði James Hawkins: > >> I'm not sure if the proposal was explicit enough, but for the RPH-esque >> functionality in Web Intents, we activate WI in the same circumstances >> RPH is activated, which is when links are activated in a page. Can you >> elucidate how the scenarios you listed could be handled? Note these >> scenarios are above and beyond RPH, but we're not trying to make the API >> self-limiting. > > Windows Explorer (the file manager) does for example offer users to edit > images upon right-click. I worry that if URI scheme handlers need not only > take care of fetching but also of presentation, other actions than view will > be unnecessarily hard to implement. Thus I figure retrieval and presentation > must be separated. > > (view (fetch uniform:resource/locator)) > or > (edit (fetch uniform:resource/locator)) > > instead of > (fetch-and-view uniform:resource/locator) Is this use case not fully handled by the UA specifying the appropriate action when building the intent, e.g., the user right-clicks on an image in a page and the UA constructs context menu items for edit/share/etc. action?
Re: [whatwg] A mechanism to improve form autofill
On Fri, Aug 3, 2012 at 5:31 AM, Aryeh Gregor wrote: > On Thu, Aug 2, 2012 at 9:42 PM, Ian Hickson wrote: > > On Thu, 26 Jul 2012, Smylers wrote: > >> Ian Hickson writes: > >> > > Also, I do not understand why we have credit cards types. Is anyone > >> > > willing to have his credit cards information saved locally? > >> > > >> > Sure, why not? > >> > >> I am too, but I can understand why people who share their computer (and > >> user accounts) with others wouldn't want their card numbers saving. > > > > That's a UA configuration issue, presumably. (Similar to saving > > passwords.) > > In fact, Chrome already autodetects credit card numbers for autofill > (presumably based on a heuristic) and has a special dialog for whether > to remember them, similar to the password-remembering dialog. At > , there are fields for both > addresses and credit card numbers. This is documented here: > < > https://support.google.com/chrome/bin/answer.py?hl=en&answer=142893&p=settings_autofill > > > IIRC, one option when it asks you to remember credit cards is "don't > ever remember credit card numbers" -- although I'm not sure, since I > think I picked it and thus haven't seen the dialog in a long time. :) > In practice the credit card portion of Chrome Autofill is not very useful since most (hand-wavy) sites that contain credit card fields in forms use autocomplete=off, which Chrome respects. There is a third-party Chrome extension which removes autocomplete=off to solve this issue. James