Summary

  • Web Intents proposed a browser-run switchboard for web services. A site could ask to edit or share a photograph without naming the service that would do it; the user and browser would make that selection.
  • Chrome put an experimental version in its stable release in 2012, with service registration limited to Chrome Web Store app manifests. Google disabled the experiment as of Chrome 24. W3C stopped work toward a Recommendation in 2013 after concerns about how the chooser fitted into user interaction.

The photo editor was someone else's problem

A photo-storage site in 2011 had an awkward choice. It could build an editor, negotiate a custom link with an editing service, or send users away to solve the problem themselves. Chromium's August 2011 Web Intents proposal offered a fourth route: describe the job, then let the browser connect the site to a service capable of doing it. Editing, viewing and sharing were early action classes. The proposal promised that a small site could gain features without making a deal with every service provider.

The browser was not merely carrying a URL. In the W3C design, a client page created an intent with an action, a data type and a payload. Service pages registered the actions and types they could handle. The user agent matched the request to a service, delivered the data and returned a result to the client. The specification compared this to the other side of a hyperlink: a link names a destination; an intent names a task and lets the user select the destination. That little shift moved a potentially valuable decision out of the page that began the interaction.

The switchboard needed a switchboard owner

A universal task broker sounds wonderfully economical until someone has to decide which services appear. The W3C draft gave the browser the registration and selection machinery. A service page could register only a handler on its own origin, and delivery required a matching action and type. The user had to take a specific action before a discovered service could receive an intent. The invoking page was barred from passively listing a person's registered services. The browser could remember preferences and avoid displaying a full chooser every time, but the user had to be able to configure delivery.

Those conditions reveal the stakes. A photo site wanted another company's editor without a private integration. An editing service wanted a place in the menu. The browser controlled the menu and the moment at which user data crossed between sites. Registration, privacy, default choices and a usable picker were one design problem, not four independent conveniences.

Stable Chrome carried an experiment

Chromium's May 2012 announcement said an experimental implementation had reached the then-current stable Chrome release. The word “stable” described the browser channel, not the maturity of Web Intents. The API was prefixed, changes might break existing experiments, and service registration initially worked only through a Chrome Web Store app manifest. Chrome hoped to lift that restriction if the API matured. The proposed open web switchboard had, in its working demonstration, a narrow entrance controlled by the browser's own store.

That detail changes the story. A web page invoking a task could test the mechanism, but an arbitrary service page could not yet simply publish the intended registration markup and expect to join the live Chrome implementation. The experimental gate determined who could show up as an option. It was a shortcut for learning, and also a limit on what that learning could prove about an open service ecosystem.

On 1 November 2012, Google engineer Greg Billock told the W3C mailing list that Chrome had disabled experimental support as of version 24. The team had found areas needing work in both the API and Chrome's specific user experience. His message did not give a usage count or a named defect. It did mark the end of the live experiment that had been invited into the stable browser only months earlier.

The standard kept the paperwork, not the picker

The W3C Working Group Note of 23 May 2013 preserved the design but recorded the groups' decision to stop pursuing a Recommendation. It also said they had performed no interoperability testing. In its June 2013 mobile-web standards review, W3C named unresolved concerns about integration into user interactions as the reason progress had stalled. The API was not rejected because the Web had no tasks to route. The proposed broker could not settle how a person would discover, choose and trust the handler that received the data.

Web Intents left a useful historical question. A site can specify a destination and own the relationship, or ask a browser to match a task and let the user choose. The second model can loosen hardcoded partnerships. It also makes the browser a market maker for services. The 2012 experiment showed how quickly an open invitation can acquire a store gate, and how hard it is to make that gate feel like the user's choice.