Intent to Migrate: Web Share Target

Hi All,
Tld;dr: Google and Mozilla would like to formally standardize Web Share Target, which is currently an incubation at the WICG and explicitly in scope of our Charter... as such, we are migrating it to the Web Apps Working Group. We invite the community to participate. 

The work will happen here (not set up yet, coming soon!): https://github.com/w3c/web-share-target

## Working group decision to adopt
It's part of the Working Group deliverables: 
https://www.w3.org/2019/05/webapps-charter.html#deliverables

### Proposal/Spec 

Repo: https://github.com/WICG/web-share-target
Specification: https://wicg.github.io/web-share-target/

### Summary
Web Share Target enables a web site to receive shared data from other sites or apps. Many modern operating systems have a "share" concept, where the user gets to pick an app to receive the shared data. The goal is to allow web apps to appear in the UI for picking an app to share to.

### Motivation and Use Cases
Currently, websites can be the target of a share, but only if the "sending" site specifically encodes the target site's URL as a share option. In practice, this means only a handful of the most popular sites appear as share targets, rather than the sites used most often by the end user. In addition, native apps, and sites using the [Web Share API](https://w3c.github.io/web-share/), can't target websites.

The Web Share Target API allows a website to become a user-selectable target when sharing from a native app or a web app (with Web Share), without having to be encoded explicily by the sending site.

For more detail, see this [explainer](https://github.com/WICG/web-share-target/blob/master/docs/explainer.md).

### Compatibility Risk
Very little, since the share target represents an optional feature for a website. A site cannot rely on this feature for core functionality, since it isn't used by the site when it is open, it's just an alternative way of opening the site.

### Ongoing technical constraints
It can be supported in all environments. As a bare minimum, just integrate with Web Share (which means the Web Share picker implemented by the browser should expose known Share Targets as options).

The more advanced implementation is to hook into the host OS's share picker, if it exists. This means it needs a separate implementation on each OS, and may require maintaining local state on the user's device (e.g., creation of a dummy "binary" to represent the web site as an app on the local system, and registration in the system registry). This could also mean local state migrations are needed when the browser updates to a new version.

### Link to implementation experience and demos
Chrome: Shipped.

Demo: https://wicg.github.io/web-share-target/demos/sharetarget.html

### Data
Currently, websites operate as share targets by promoting "share buttons" (e.g., [Facebook share button](https://developers.facebook.com/docs/plugins/share-button/), [Twitter tweet button](https://developer.twitter.com/en/docs/twitter-for-websites/tweet-button/overview)), which other websites are expected to place on their site. This gives the power to receive shares to a small handful of very popular sites. Web Share Target allows any app-like site to be able to receive shares without having its share button embedded on all the other sites.

### Security and Privacy
See [Security and Privacy Considerations](https://wicg.github.io/web-share-target/#security-and-privacy-considerations).

### Accessibility
The specification requires the user agent to implement or invoke a user interface. However, the specification does not define any properties of that UI, and in many cases, the user agent won't implement a new UI (it will defer to existing OS interfaces).

### Internationalization
The UI will display app titles, which may need to be internationalized. To do this, we defer to the [Manifest internationalization policy](https://www.w3.org/TR/appmanifest/#internationalization) (which is frankly not great, as it requires a separate manifest to be shipped for each locale).

One complication is that Web Share Target is often implemented statefully, e.g., by creating a proxy binary or script on the host system, which means if the user changes their locale after installing an app, that app will use the name from the locale when it was installed. However, this is a problem for the manifest, not specific to WST.

Kind regards,
Marcos and Leonie - WebApps Working Group Chairs

Received on Friday, 5 June 2020 05:19:51 UTC