Intent to Implement: Web Share API

[Matt Giuca]

Contact emails

{mgiuca,sammc,benwells,owencm}@chromium.org

Spec

https://github.com/mgiuca/web-share/blob/master/docs/interface.md

Design doc:
https://docs.google.com/document/d/1O6bhp9QpoLc2KXTf2FpmLoaAS6XW6TsyAIpLcmBTpnM/edit (old)

Summary

Web Share [1] is a proposed API for sharing data (text, URLs, images) from the web to an app of the user's choosing. In this first phase, we plan to implement website-to-native-app sharing in Chrome for Android.

In the Android version, a web page should be able to trigger a SEND intent. We later hope to allow websites to receive SEND intents using the Web Share Target API [2], but that will be dealt with in a separate proposal. The implementation will initially be behind the web platform experiments flag.

This project retreads old ground of Web Intents and Web Activities, but neither of those got any traction. We are starting with a very focused, one-way API for a single use case, and we have some good answers to the problems those systems encountered [3]. We have UX mocks for mobile [4].

[1] https://github.com/mgiuca/web-share

[2] https://github.com/mgiuca/web-share-target

[3] https://github.com/mgiuca/web-share/blob/master/docs/explainer.md#frequently-asked-questions

[4] https://github.com/mgiuca/web-share/blob/master/docs/explainer.md#user-flow

Motivation

Websites are currently unable to trigger a generic "share" event to share text or URLs to a destination of the user's choosing. Users of Chrome on mobile are able to choose "Share" from the Chrome menu to share the current page URL to any native app, copy to clipboard, etc. However, from within the page itself, web developers' options are limited.

On Android, web pages can link to a special "intent://" URL [5] to send an intent, but this requires the web page to craft an intent in the Android intent URL syntax, which will never be supported on other platforms. Also, these intents are limited to apps that opt to receive the CATEGORY_BROWSABLE category (at the time of writing, very few). We could work to loosen this restriction, but we would prefer to build a platform-neutral API that can target native apps on a variety of platforms (as appropriate), as well as (eventually) web apps on all platforms.

Many websites today feature an array of social sharing buttons to share content to popular destinations like Facebook and Twitter, using services like ShareThis [6] and AddToAny [7]. This has two significant downsides: the destinations must be hand-picked by the site author (not the user), and the action cannot be sent to native apps (e.g., SMS tools or the native Facebook app). The Share API would allow sites to provide a generic "share" button that triggers the underlying platform's natural share mechanism.

[5] https://developer.chrome.com/multidevice/android/intents

[6] http://www.sharethis.com/get-sharing-tools/

[7] https://www.addtoany.com/

Interoperability and Compatibility Risk

If only a subset of browsers ship it then websites will have this capability in some but not all browsers / platforms. However, we anticipate that sites will usually provide a fallback for using this API anyway, since regardless of whether the browser supports it, the user may not have any share targets available. For example, sites may present a Web Share button in addition to the existing array of specific social buttons. Therefore, the impact of not having this API on all browsers/platforms, or even of removing this API, should not break sites. The usual compatibility risk of any new method applies: if web developers do not properly detect the presence of the feature before using it, their site may break on other browsers, or on future Chrome if we decide to remove the feature.

If we cannot subsequently standardize the Web Share Target API [2], then this will be limited to sharing from the web to native apps, and may not be supportable on all platforms.

We intend to run an Origin Trial [8] once the initial implementation is complete to allow us to assess the API design. We are not yet announcing an intent to ship.

Mozilla has expressed some interest in use of the Ballista API (an earlier generalized version of Web Share) [9] as a replacement for Web Activities; they have not specifically commented on Web Share. No public signals from other browser vendors.

[8] https://github.com/jpchase/OriginTrials

[9] https://github.com/w3c/manifest/issues/442

Ongoing technical constraints

Parts of the Web Share implementation would assume certain OS-specific features such as Android intents. However, the API specification will not be Android-specific; it will be open-ended as to how the implementation should deliver the share event to the system.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No (Android only, for now). Web Share has to be specifically implemented for each platform (because it is an OS interop mechanism), and we are starting with Android because there is an obvious mapping from Share to Android intents. We don't intend to ship until we have covered a wider set of platforms.

OWP launch tracking bug

https://crbug.com/620973

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5668769141620736

Requesting approval to ship?

No.

[Anne van Kesteren]

I'm extremely surprised you stopped talking to us. January 15, 2015, I
told you that focusing on a specific extension, sharing in particular,
would much more likely to be successful since it's easier to get the
UX right. We're now a year and a half further and you're proposing to
do exactly that without having ever really gotten back to us, as far
as I can tell.

On top of that, some of us at Mozilla had proposed going after sharing
back in 2014:

https://wiki.whatwg.org/wiki/Sharing
https://wiki.whatwg.org/wiki/Sharing/API

Having said that, if the sharing is just with native that does not
seem super interesting.

[Matt Giuca]

Hi Anne,

Sorry for radio silence. We did a round of public discussions, took on board all the feedback (including yours, which was to focus more tightly), and then spent a bunch of time rewriting. This is the result.

On Fri, 17 Jun 2016 at 16:32 Anne van Kesteren <ann...@annevk.nl> wrote:

I'm extremely surprised you stopped talking to us. January 15, 2015, I
told you that focusing on a specific extension, sharing in particular,
would much more likely to be successful since it's easier to get the
UX right. We're now a year and a half further and you're proposing to
do exactly that without having ever really gotten back to us, as far
as I can tell.

It was January 2016, it's only been six months, not a year and a half. Still, that's quite a long time; I had intended to send this ITI much sooner, but it got stuck in internal reviews.

 

On top of that, some of us at Mozilla had proposed going after sharing
back in 2014:

  https://wiki.whatwg.org/wiki/Sharing
  https://wiki.whatwg.org/wiki/Sharing/API

We looked at those proposals awhile ago. The main problem I had with them was that they featured procedural registration, not declarative (through web manifest). Obviously being from 2014 those features weren't available at the time.

We'd love to work with Mozilla and other browser vendors to try and make a standard, as we discussed in January. I have posted about this to WICG in the last few days:

https://discourse.wicg.io/t/web-share-api-for-sharing-content-to-arbitrary-destination/1561

and it's probably better to discuss the proposal on there than on blink-dev which is more specific to the Blink implementation.

Having said that, if the sharing is just with native that does not
seem super interesting.

I agree. The result of the internal discussions we had about this were that this would have a better chance of being standardized if it were broken up into even smaller pieces than I had originally intended. So we split it into Web Share and Web Share Target APIs. I really want to see this work in both directions, but I think starting with a one-way share out is a good way to start.

Cheers

Matt

[Jochen Eisinger]

Can you share a bit more about what we learned from Web Intents and how the Web Share API is going to address those shortcomings and problems that led us to stop Web Intents back then?

[Matt Giuca]

The original Ballista explainer addresses Web Intents:

https://github.com/chromium/ballista/blob/master/docs/explainer.md#how-is-this-different-from-other-web-interoperability-systems

(But a lot of that is not relevant in the simple share case.)

The main lesson we're being repeatedly told is to not be over-ambitious. The generality of Web Intents meant the UI was hard to get right, and it was hard to get buy-in on the web developer side.

The Share proposal is just a simple sharing API, that doesn't require web receivers in order to be useful.

[Paul Kinlan]

I wrote up a number of things about the issues with Web Intents:

* UX Issues - https://paul.kinlan.me/what-were-the-ux-issues-with-web-intents/ (note I just realised there are todo's in it still)

* Web Intents in general - https://paul.kinlan.me/what-happened-to-web-intents/

* Sevice Discovery thoughts: https://paul.kinlan.me/service-discovery-on-the-web/

* Thoughts on intent scheme: https://paul.kinlan.me/every-browser-should-support-intent-urls/

* Sharing Natively on Android from the web: https://paul.kinlan.me/sharing-natively-on-android-from-the-web/

I like Matt's proposal and I think that working on Share - which is the largest use for Android - is a good place to start. There are lots of use-cases that we can discuss in the space, just as sharing Binary data in the ShareData interface (images for example).  Personally, I like the manifest to register for handling "Share" actions, but I think there is more scope even in this space for types of sharing (but I can comment on the repo's)

P

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[nekr....@gmail.com]

I can be wrong and I didn't read all the docs yet, but isn't it bad to tie this API to WebAppManifest and to SW? I mean, Safari may never have SW and app manifest, but may want to implement Share API.

[Matt Giuca]

On Sat, 18 Jun 2016 at 00:12 <nekr....@gmail.com> wrote:

I can be wrong and I didn't read all the docs yet, but isn't it bad to tie this API to WebAppManifest and to SW? I mean, Safari may never have SW and app manifest, but may want to implement Share API.

That's a great question. It's one of the main reasons we split the Share and Share Target APIs. Share does not depend on Service Worker and Web App Manifest; Share Target does.

We recognized that Safari and Edge may not be able to implement Share Target in the short term, but they would at least still be able to implement the basic Share API.

[Jochen Eisinger]

So if the UI for Web Intents was hard to get right on all platforms, and at the same time you indicated that you'd only ship once you have a non-Android implementation, how will the UX look like on non-Android?

[Elliott Sprehn]

On Tue, Jun 21, 2016 at 1:25 PM, Jochen Eisinger <joc...@chromium.org> wrote:

So if the UI for Web Intents was hard to get right on all platforms, and at the same time you indicated that you'd only ship once you have a non-Android implementation, how will the UX look like on non-Android?

That's the benefit of splitting the feature into sharing outward only to native to start. For that we can show the native share dialog/sheet that users would see in Android or iOS apps. To allow Web->Web or Native->Web sharing it'll require something different.

[Jochen Eisinger]

Oh, so the plan is to eventually ship on platforms that natively support sharing first? Matt, could you please clarify that?

[Ben Kelly]

FWIW, I think some of us at Mozilla have concerns about making features require manifest.  It would be nice to also support meta tags or a js API.

In any case it would be great to resume collaborating on this.  I think a bunch of people are travelling now, but maybe we can do a video call in coming weeks?

Thanks!

Ben

--

[Jochen Eisinger]

WebShare (the part proposed here) doesn't interact with the manifest at all, no?

[Matt Giuca]

On Tue, 21 Jun 2016 at 22:59 Jochen Eisinger <joc...@chromium.org> wrote:

WebShare (the part proposed here) doesn't interact with the manifest at all, no?

That's correct. Web Share would have nothing to do with the manifest. (The Web Share Target API being separately proposed is designed to go in the manifest, but that's obviously flexible.)

> So if the UI for Web Intents was hard to get right on all platforms, and at the same time you indicated that you'd only ship once you have a non-Android implementation, how will the UX look like on non-Android?

For Web Share (ignoring web receivers), the UX would just be each platform's native share UI (iOS Share Sheet, Windows 10 share contract picker).

> Oh, so the plan is to eventually ship on platforms that natively support sharing first? Matt, could you please clarify that?

There are no plans to ship at this stage. We are just planning to implement on Android as a prototype, then go have more discussions.

There are basically three platforms that we know of that natively support this kind of sharing:

- Android

- iOS

- Windows 10

Of those, I believe Chrome can only support the first two (Windows 10 requires a UWP app which Chrome is not). So maybe if we did ship, we'd do it in close timing on Android and iOS. Other vendors could ship on Windows 10 if they have a UWP app (I'd imagine Edge could do this).

Ben Kelly <bke...@mozilla.com> schrieb am Di., 21. Juni 2016, 14:56:

FWIW, I think some of us at Mozilla have concerns about making features require manifest.  It would be nice to also support meta tags or a js API.

We could do that. One of the reasons we want the manifest is because then the data about what things the site can handle is declarative and associated with the whole site (not individual pages).

Using meta is still declarative, but then it's associated with individual pages which is not ideal when we're talking about what things the service worker can handle (there is no HTML page that is directly involved with Web Share Target API, so it seems odd that you would declare it in an HTML page). Using a JS API is non-declarative which makes it hard to index, and hard for the browser to control when to prompt the user. But I'm open to all of these things. Note that this is not relevant to the Web Share API being proposed.

In any case it would be great to resume collaborating on this.  I think a bunch of people are travelling now, but maybe we can do a video call in coming weeks?

I'd love to have a video call to start the discussion going between different browsers. Let me know when you expect to be back to normal. (FYI, the team primarily working on this from the Chrome side is in Sydney, Australia, which can make scheduling hard, but we can work around your schedule.) 

[Ben Kelly]

On Jun 22, 2016 3:32 AM, "Matt Giuca" <mgi...@chromium.org> wrote:
>> Ben Kelly <bke...@mozilla.com> schrieb am Di., 21. Juni 2016, 14:56:
>>>
>>> FWIW, I think some of us at Mozilla have concerns about making features require manifest.  It would be nice to also support meta tags or a js API.
>
> We could do that. One of the reasons we want the manifest is because then the data about what things the site can handle is declarative and associated with the whole site (not individual pages).
>
> Using meta is still declarative, but then it's associated with individual pages which is not ideal when we're talking about what things the service worker can handle (there is no HTML page that is directly involved with Web Share Target API, so it seems odd that you would declare it in an HTML page). Using a JS API is non-declarative which makes it hard to index, and hard for the browser to control when to prompt the user. But I'm open to all of these things. Note that this is not relevant to the Web Share API being proposed.

Sorry, I was referring to the target proposal.

I'll have to look in more detail after I'm back, but it seems maybe a target API could live on the service worker registration like the push subscription.  Sites could choose to add the share target when it's most appropriate just like they do with push.  At first glance these use cases seem kind of similar.

I'll touch base next week.  Marcos also lives in Australia, though, so maybe he would be a good point of contact.

Thanks!

Ben

[Anne van Kesteren]

On Tue, Jun 21, 2016 at 1:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> That's the benefit of splitting the feature into sharing outward only to
> native to start. For that we can show the native share dialog/sheet that
> users would see in Android or iOS apps. To allow Web->Web or Native->Web
> sharing it'll require something different.

I think the big difference is that iOS and Android offer a button at
the system-level. It's not really triggered by a site, but by the user
invoking browser (system) UI. This is also the UI Safari on a Mac
offers.

That was the kind of UI our work from back in 2014 tried to target as
well (and Firefox has experimented with too).

This proposal requires integration from both those that have something
to share and from those it can be shared with, which seems much
trickier to successfully deploy. I'm also not convinced it gives the
right user experience as you lose the button that users are getting
familiarized with.

In a way this proposal is still Ballista, except now share is part of
the API names, rather than a parameter.


--
https://annevankesteren.nl/

[Matt Giuca]

On Thu, 23 Jun 2016 at 20:12 Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Jun 21, 2016 at 1:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> That's the benefit of splitting the feature into sharing outward only to
> native to start. For that we can show the native share dialog/sheet that
> users would see in Android or iOS apps. To allow Web->Web or Native->Web
> sharing it'll require something different.

I think the big difference is that iOS and Android offer a button at
the system-level. It's not really triggered by a site, but by the user
invoking browser (system) UI. This is also the UI Safari on a Mac
offers.

Right, lots of browsers are now offering Share buttons at the browser UI level. Web Share is (at the first stage) about essentially giving web pages a programmatic API to trigger that Share button.

That was the kind of UI our work from back in 2014 tried to target as
well (and Firefox has experimented with too).

Does this still exist in Firefox? I see this documentation but don't see the share button in my Firefox 47 UI (on Linux).

This proposal requires integration from both those that have something
to share and from those it can be shared with, which seems much
trickier to successfully deploy.

It shouldn't require integration from "those that can be shared with"; with just Web Share, we'll require participation from "those that have something to share" but the targets will be automatically available: on Android as a system intent, on iOS as a system share, on Windows 10 UWP apps could share to the system contract, etc. On OSes that don't have a native share system, the browser can still provide its own sharing system (as Mac Safari does, and Firefox apparently did or does). We don't want to specify what the UI is or exactly how the browser should let users pick the target (i.e., whether there's a hardcoded list or whether the browser lets the user add arbitrary sites; whether the browser automatically posts to Twitter as Safari does or whether it just opens a new twitter.com tab pre-filled with the message). We just want a way to trigger the share of some site-specified content.

This won't necessarily make sense on all browsers and platforms, but as a progressive enhancement feature, it doesn't have to (as long as we get agreement from many browser vendors; we don't want this to be a feature specific to one vendor).

I'm also not convinced it gives the
right user experience as you lose the button that users are getting
familiarized with.

I'm not proposing to remove the browser-ui-Share buttons. This would be an alternative mechanism for sharing.

In a way this proposal is still Ballista, except now share is part of
the API names, rather than a parameter.

Yes, it is. We aren't trying to distance ourselves from Ballista, but rather break off small workable pieces of the original Ballista proposal. We had a lot of discussions where we were told "you aren't going to be able to standardize the Ballista API in a single go; focus small." So we did.

One casualty of that is that the API itself got less generic. For those who didn't see the original Ballista proposal, it was something like this:

navigator.actions.performAction({verb: 'share'}, {...})

and now it is

navigator.share({...})

This implies that if we do continue to build more of these Ballista capabilities after Web Share, they may end up all being separate top-level methods instead of a more generic "performAction" or similar. But just focusing on Web Share as the proposal stands today, it doesn't make a whole lot of sense to have the generic method. I think if we went with the generic performAction, library authors would likely end up providing similar abstractions over it anyway.

 

--
https://annevankesteren.nl/