Intent to Migrate Web Share API

[marcoscaceres]

Intent to Migrate: Web Share API

Hi Folks working on this... with the Web Apps WG now up and running, we are ready to adopt this specification into the WG for formal standardization along the w3c rec track. 🎉

Before doing so, I could use a bit of help just filling out the template below... I've got things started already, but those with knowledge of the spec please jump in.

Working group decision to adopt

In W3C WebApps Charter

Proposal

https://github.com/WICG/web-share/

Adopt level/version 1 and 2?

Summary

An API for sharing text, links and other content to an arbitrary destination of the user's choice.

The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.

Motivation and Use Cases

Described in the explainer.

Compatibility Risk

Please characterize how much we might regret standardizing this new feature were we to change or remove it in the future. If you don’t have a github repository, include in this email links to relevant discussions, or documentation about support for the feature on the Web.

As the feature is shipping in two browsers, there is risk with making too many changes to v1 of this API. However, it would be good to perform conformance/interop testing, and address any issues during the next phase of the standardization process.

Ongoing technical constraints

Discussion of options on various operating systems:
https://github.com/WICG/web-share/blob/master/docs/native.md

Not supported as a native feature across all operating systems. It is foreseeable that browsers could "share" across web apps, via the Share Target API.

Link to implementation experience and demos

Implemented in Chrome (since 61) and Safari (since 66).

Was also trialed/used on twitter.com. (still used there?)

Data

What data do you have available that indicates that this enhancement will affect many users of the Web. Quantify the fraction of websites that are currently using something similar to this feature. Or, if a new feature, characterize the reason that you expect this to be far reaching.

Security and Privacy

Outline the security and privacy implications of your proposal for end-users. Otherwise, indicate if there are none.

Accessibility

Outline the implications of your proposal relative to access by everyone regardless of disability. Otherwise, indicate if there are none.

Internationalization

See issue #6

[ewilligers]

Blink is preparing to ship Level 2 (file sharing): chromestatus.
Some of the questions may have been addressed in the Intent To Ship.
Usage has been low. We are anticipating an increase when Level 2 ships.

[marcoscaceres]

@ericwilligers, ok cool. Have you reached out to anyone on the Safari/WebKit team to gauge their interest? I've not had a chance to look at the L2 stuff yet from a Mozilla perspective.

[ewilligers]

We have kept the Safari team (@hortont424 @hober) updated about out plans, but haven't heard if there is Apple interest in the Level 2 functionality.

[hober]

We have kept the Safari team (@hortont424 @hober) updated about out plans, but haven't heard if there is Apple interest in the Level 2 functionality.

I'm sorry if I've missed something; did you CC us on a GitHub issue or something? Odds are very good that I won't see something if it's lost in the firehose of GitHub notifications.

[ewilligers]

did you CC us on a GitHub issue or something?

Not GitHub. I'm referring the "Web Share API future directions" emails from Matt, Tim in October and from myself in April.

[edent]

Is there any user research on how people use this? Do users recognise that it is their device's native sharing dialogue, for example?

[ewilligers]

I don't think there has been any user research.

[edent]

I don't see how this can continue without any user research.

Is there evidence that actual users want this? If not, how can we know if this is a useful feature?

[raymeskhoury]

Is there evidence that actual users want this? If not, how can we know if this is a useful feature?

There are close to 1,000,000 navigator.share calls each day from Chrome on Android browsers, which is significant evidence.

[philnash]

Do you also record how many of those navigator.share calls result in a successful share? I'm a fan of this as a developer, but the success rate might well show more what users are experiencing.

[ewilligers]

Here are some early estimates from https://www.chromestatus.com/metrics/feature/popularity

About 0.0069% of pages are calling share().

About 0.0050% of pages are experiencing a successful share() that involves files.
About 0.0036% of pages are experiencing a successful share() that does not involve files.
About 0.0012% of pages are experiencing an unsuccessful share().

Here, success means that the user selected a share target, and so the promise resolved.

Pages may call share() more than once. We don't directly record the percentage of share() calls that result in a successful share.

[edent]

OK, that's a good start. Has there been any direct user research? That is, conversations with end users to see what their intention is? Whether they like the experience? If it meets their needs?

[grorg]

What results do you expect out of the user study? Since this API triggers the native UI, wouldn't the results be very dependent on the platform?

Also, while users are obviously the most important, the API was designed for developers. The goal is to give them an alternative to embedding endless share options in their content. How would you ask end users whether or not that goal was achieved?

[GirlyGeekdom]

I'd be fascinated to understand your user scenarios. Do you see this being for anything or for specific scenarios. Public or private sharing? These are fundamentally different things and from a user perspective they are really important.

Consider this scenario. Social media content sharing. This could be done in the way you described in your outline however beyond the endpoint, content and source there are some other parameters that also get shared such as location, cookie tracking data, shared via app name etc.

If you consider it in terms of I want to share an image with my friend... I may wish to also share my location, my availability and my mobile number.

But if I were to share the same information with a stranger I wouldn't want them to have any of the extra information. But I may want to know more about who they are and why they want my data.

The concept appears on the surface as simple but in reality if this is going to be useful and for the benefit of the users then it needs a user centric approach.

[marcoscaceres]

@GirlyGeekdom wrote:

I'd be fascinated to understand your user scenarios. Do you see this being for anything or for specific scenarios. Public or private sharing? These are fundamentally different things and from a user perspective they are really important.

We are incrementally building this up on the most simple share types... so, starting with just some text and URLs.

Consider this scenario. Social media content sharing. This could be done in the way you described in your outline however beyond the endpoint, content and source there are some other parameters that also get shared such as location, cookie tracking data, shared via app name etc.

Good point. For privacy reasons, we want to limit things like that above as much as possible (specially tracking cookies... thought tracking identifiers could be shared by the URL, like those pesky utm_* search params).

If you consider it in terms of I want to share an image with my friend... I may wish to also share my location, my availability and my mobile number.
But if I were to share the same information with a stranger I wouldn't want them to have any of the extra information. But I may want to know more about who they are and why they want my data.

Sure... the share dialog could give you control over that (if we eventually add support for sharing location in the future).

The concept appears on the surface as simple but in reality if this is going to be useful and for the benefit of the users then it needs a user centric approach.

Agree... definitely something we will incrementally work towards over time.

[marcoscaceres]

@mgiuca, I'd like your ok before moving this to the Web Apps WG.

Some things that we will need address once we move this: the Level 2 features will need to be merged into L1, but as pull requests requiring multiple browser vendors to give implementation commitment (as per the WebApps Charter).

[marcoscaceres]

@mgiuca, ping. WDYT? Ready for us to move this over?

[mgiuca]

Yes, I'm ready to move this under the WebApps Charter.

Will this mean any changes for the spec organisation? I would imagine this moves the GitHub URL from WICG, but would it stay in its own spec for the time being?

I'm not sure why L2 needs to be merged into L1. We designed L2 not as a "version 2 of the spec" but rather as a second level of implementation support, with the idea that L1 is fairly straightforward to implement, whereas L2 is more complex and also might not make as much sense on some platforms (if they can't share binary data), so we made those features individually detectable. I think there's value in an implementation striving to support the L1 features first before hitting L2. If it simplifies things, though, we can combine them into one spec.

[marcoscaceres]

Will this mean any changes for the spec organisation?

No. It shouldn't. It will become an "ED", which we can then publish as a FPWD. But that's it.

I would imagine this moves the GitHub URL from WICG, but would it stay in its own spec for the time being?

Yes, it will stay as its own spec, and we can set up a redirect to keep the current URL... everything should work as it does today.

I'm not sure why L2 needs to be merged into L1. We designed L2 not as a "version 2 of the spec" but rather as a second level of implementation support, with the idea that L1 is fairly straightforward to implement, whereas L2 is more complex and also might not make as much sense on some platforms (if they can't share binary data), so we made those features individually detectable.

The technical challenges are somewhat independent of the standardization challenges: standardization for L2 is centered around getting other browser vendors to commit to implementing L2 features... in other words, we need to convince Mozilla and Apple to get behind aspects of L2.

We then have options: we can send things as Pull Requests to be part of L1 with the proviso that everyone agrees to implement in a timely manner. Or we can sit things in pull requests, until such time that implementers are willing to support whatever feature (the "WHATWG working mode"). Or we leave make a new "web-share-2" repo here, which allows for the continued incubation of Share L2, but with the ultimate aim of getting a second implementation.

Personally, I prefer the "WHATWG Working Mode" - which closely matches the requirements from the WebApps Charter and is enforced by the PULL_REQUEST_TEMPLATE associated with each WebAppsWG repository.

I think there's value in an implementation striving to support the L1 features first before hitting L2.

We are already there, no? With Chrome and Safari - and Firefox on the way. There are some interop issues/edge cases, but no show stoppers.

If it simplifies things, though, we can combine them into one spec.

It does in as far as it reflects "standardization" (i.e., two or more browsers willing to support a feature). It also forces us to be more rigorous with each proposals: two interoperable implementations, complete with a full test suite, for each new feature. By forcing 2+ implementation and testing, we end up with a much higher quality spec and we are able to catch many more bugs before anything lands in the spec.

Let me know if the above raises additional questions. If no, I can begin the process of transitioning this over.

[mgiuca]

We are already there, no? With Chrome and Safari - and Firefox on the way. There are some interop issues/edge cases, but no show stoppers.

Right, but that's exactly why the split is helpful, because we have L1 reasonably agreed and implemented, but L2 is a bit more shaky.

Seems like for now it's worth moving L1 into ED and then we can decide later whether to move things from L2 in there or create a second Level 2 document in the Apps WG. (We might decide on a case-by-case basis, for example canShare might move into the L1 while file sharing might remain as an optional feature.)

Let me know if the above raises additional questions. If no, I can begin the process of transitioning this over.

Go ahead and move it over. Thanks!

[marcoscaceres]

@siusin, as per above, could you please transfer this repository to the W3C org for us?

[siusin]

Thanks all. This repo has been transferred to the W3C org.

The WebApps-WG GitHub team members will have the write access to this repo (and the other webapps wg repos). Please let us know if you would like to be part of this team.

[marcoscaceres]

Group notified:
https://lists.w3.org/Archives/Public/public-webapps/2019JulSep/0009.html

@siusin, or @mgiuca, could you also make admin on this repo?