Intent to Migrate to WebApps WG

[mgiuca]

Intent to Migrate: Web Share Target

Originally proposed at #85. Living document.

Working group decision to adopt

It's part of the deliverables:
https://www.w3.org/2019/05/webapps-charter.html#deliverables

Proposal

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

Note that if migrated to the WG, we may fold the Web Share Target specification into the existing Web App Manifest spec which is where it belongs (since the entire API surface is a new Manifest member).

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, 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.

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

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.

Currently, websites operate as share targets by promoting "share buttons" (e.g., Facebook share button, Twitter tweet button), 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

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

See Security and Privacy Considerations.

Accessibility

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

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

Outline the implications of your proposal when used with different languages, scripts, and cultures. Otherwise, indicate if there are none.

The UI will display app titles, which may need to be internationalized. To do this, we defer to the Manifest internationalization policy (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.

[mgiuca]

@marcoscaceres I'm finished writing this up. What now?

[marcoscaceres]

Just need to double check that Mozilla folks are still behind this (last I checked, we were). That gives us the second potential implementer and quorum to move this the WebApps WG.

[marcoscaceres]

I'll prepare the CFC for the WebApps WG.

[marcoscaceres]

Ok, got a 👍 from Mozilla... let's move this over as we now have two implementers interested. 🎉

[marcoscaceres]

Notified the WG...
https://lists.w3.org/Archives/Public/public-webapps/2020AprJun/0008.html

[marcoscaceres]

@sideshowbarker, could you transfer this repo over to the W3C for us?

[sideshowbarker]

OK, done

[marcoscaceres]

@sideshowbarker or @siusin, sorry, could you also add me as repo admin?

[sideshowbarker]

@sideshowbarker or @siusin, sorry, could you also add me as repo admin?

yup — done