Explanation of the Web Share API (translated)

Original address: Https://github.com/WICG/web-share/blob/master/docs/explainer.md

Web Share is a proposed phase of the Web API that allows you to share data (text, URLs, images, and so on) in any target application, such as system services, local apps, or other Web sites. Developers can create a common sharing button that can trigger a system-shared session when the user clicks.

The Share project (Ballista project), which is owned by the Web, is a sub-project of chromium, which is dedicated to communicating interactions between websites and websites, websites and local applications.

Operation Flow

Shows how users can share the URL of a picture to a local app using Web share on a Web page. While it looks like Android, we're looking to design it as a common feature of the PC and mobile operating systems.

1, the user to browse a picture site, and then click on a picture of the share link, the site calls Navigator.actions.performAction (' share '), with a topic information and a message (in general, the message is a URL).

2. Displays a dialog box that provides options for local app and system operations (such as Gmail, Facebook, copy to clipboard). On Android, these options are system default, but in other browsers and operating systems, these options may vary.

3, the user clicks Gmail, the local Gmail automatically opens, the topic information and the message automatically migrated to Gmail.

Sample code

To allow users to share the URL of the current page to another app or website, simply add the following code to a button:

Sharebutton.addeventlistener (' click ', () = {

Navigator.share ({title: ' Example Page ', url:window.location.href})

. Then (Console.log (' Share successful '));

});

You can also check to see if the app is installed, or if the browser supports Web Share, to decide whether to show the share button to the user.

if (!navigator.canshare ())

Sharebutton.hidden = true;

Problems

What is the necessity of this function?

We want users to be able to quickly share what they find on the web to the app and quickly invoke system services (social communications, text messages, sticky notes, etc.) that process content.

There are two options available to share content from the Web:

1. Share to a few specific websites (such as Facebook and Twitter share buttons).

2, the browser built-in Share button. Many browsers, especially mobile browsers, have a share button that lets you share the URL of the current page to your local app.

Scenario one is not ideal because the goal of sharing is set by the site, users are not able to choose, and the goal is limited to a few specific sites.

Scenario Two also have some problems: the Web site developers have no way to build a share button on the page, the content limit can only be URL, the browser interface may not exist, such as when the Web page into a separate, full-screen application.

So we want to create an API to solve the problem above, so that users can share any content on the site to any app.

How do Web Apps get content shared by other Web pages?

We certainly also want to be able to control the reception of content, not just the delivery of content. For this we have made this feature a separate proposal: the Web Share Target API.

What is the difference between WEB share and existing session/sharing systems (Intent/share system)?

What the Web share has done (creating a common Web Session system) has been a lot of attempts, typically such as web intents and Mozilla's web activities, which all two projects have stopped developing.

We intend to fully address the problems encountered by these projects, but for the moment we are only focusing on the web

Share this entry point to avoid the changes in requirements and scope of the previous project.

We are also trying to solve the problem of having to rely on developers to write code to start local applications through Web share, which enables instant invocation of local applications.

Iv. Why not use Android's Intent:urls?

Special links intent://URLs can be used on Android, and now Chrome and Firefox have been implemented. Clicking on such a link will trigger the Android Intent,intent to call an app directly (with Android package name) or indirectly (show the app's icon).

Web pages can use this method to implement common sharing buttons, but the scenario has the following issues:

1, only applicable to Android;

2, for security reasons, only those who allow to receive intent Android app can be called intent, in fact, such Android app is very few;

3. Only the local app can be associated with the website.

It is therefore necessary to redefine a standard API for the Web.

Why not make a sharing protocol (URI Scheme), just like mailto: instead of making a JavaScript API?

This is an interesting proposal that has appeared many times. We can introduce a new URL Scheme, such as share:, and then write a share button:

<a href= "share:?title=example%20page&amp;url=https://example.com/page" >share this</a>

This scenario does have several advantages over the DOM API:

1. Links can be written in HTML in a declarative style, without the help of JavaScript;

2, the webpage can receive the message through the existing Registerprotocolhandler API, there is no need to do a share Target API.

However, there are still some problems in this scheme in practice:

1, share the current page link, you may need to use some additional scripts to assign the URL of the current page to the HREF attribute;

2, no API can indicate whether the user's system supports sharing;

3. After performing the sharing operation, no feedback information.

There is also a theoretical problem: URIs are primarily used for tagging resources (identify resource), not for specified operations (specify actions). Therefore, the scheme has the suspicion of misuse of URIs.

Of course, it is possible to explore this scenario as an alternative to the DOM API.

Explanation of the Web Share API (translated)