Web Share API #27
Comments
|
Without claiming expertise in this area, I've reviewed the specification and raised a few small concerns with the design of the API (mostly just nits) - but overall, I think it's worth supporting from a standards perspective. The main concern I have is with the API appearing and disappearing depending on registered share targets. I've requested that the API just have On the plus side, there are already Web Platform Tests for the API. And Google has run an origin trial for it. We can reach out to @mgiuca if we need additional information about the trail and site adoption. I'd also note that there is interest from the Fennec side. Hi, @andreasbovens! We probably want input from @mixedpuppy, as he is really the authority on sharing at Mozilla. And @annevk has given this a lot of thought too, so would be great to get a 👍 from him. |
|
Some more info and links:
Thanks. Does that correspond to Issue 59 which you just filed? Let's continue the discussion there. Really looking forward to seeing alternative implementations of this! |
I'd forgotten that we had discussed that issue some time ago. I've withdrawn my objection - current design works ok. |
|
I just wanted to voice my support for this Web Share API proposal, and reference earlier work by Mozilla in this area with the Web Activities API. The very simple Web Share API proposed here is a pragmatic approach to this long standing feature request for the web. Extending this proposal to facilitate the sharing of different file types (e.g. images, audio and video), perhaps with an additional field in the shareData dictionary to specify a MIME type would make it even more useful, but starting with the basic feature set may be a good idea. Also note the companion Web Share Target API proposal which isn't quite as far along, but would be essential to ensure the "sharing" doesn't just flow in one direction from the web to native apps. |
|
Thanks Marcos and Ben! Re Web Share Target: please link to the WICG copy of this repo, not my personal copy (which may be out of date at any given time if I forget to push to it). |
|
A bunch of us met at the Mozilla All Hands last week in Austin, including @snorp, @andreasbovens, @mixedpuppy, @annevk, @st3fan, and @garvankeeley (apologies if I forgot anyone!) to discuss the spec. This represented the DOM Team, Android/iOS Fennec, Products, and Firefox Extensions. IIRC, we concluded that the current approach taken by the API seems to address the use cases we've had in mind, and we would encourage @dbaron mark this as |
|
Sorry to miss this discussion during All Hands. From what I have read about the current approach so far, it seems to bias or at least designed specifically for (in API and UX) large content silos, reinforcing the default centralization hegemony. I'd rather not even take this "under consideration" until we see evidence that the use-case of "share to your own website" is demonstrated by spec advocates, and preferably as easily as any "share to a social media silo" use-case. |
This is certainly true - in as far that a user agent supporting this API would only enable preregistered silos. For example, this is what Safari/OSX provides today (to be clear, Safari doesn't support the API... just provides share defaults via the OS):
Now, the separation between the Share API and the Share Target API is intentional because we want to incrementally evolve both specs. Similarly to Payment Request API and Payment Handler API, with Web Share, we get a (relatively) quick win by enabling "the silos", while also opening the opportunity for anyone to become a share target.
Without the Share Target API, you would be absolutely correct. However, Share Target API is being developed in parallel for that reason.
I think we all want to see Share Target succeed also, but it's a matter of resourcing and picking our battles. With Web Share, @mgiuca chose to initially attempt to solve just a small piece of the puzzle (which - hopefully I'm not mischaracterizing anyone's position here - those involved in the meeting concluded did a reasonable job, given what we understand of the use cases). Now, however, we may opt to evolve both standards together... but we know from Web Share and Web Activities that this can quickly spin out of control. Thoughts about how we should proceed? |
|
Let's start with do no harm. That is, we should oppose anything that is actively harmful for the web, that's part of the point of this whole repo/process. I believe WebShare in its current form is an (unfortunate) example of this (per the silos in the screenshot from @marcoscaceres above). I'm also confident in the good intentions from the authors, having had a chat with @mgiuca nearly 2 years ago about it. In those two years however, vertical content silos have only become more of a problem, for the web, and frankly, whole societies/democracies. I'd rather not help pour more fuel on the centralization trash fires. |
|
Given the Share Target spec, which is supposed to address the centralization concerns, what would be the ideal way for this work to proceed (or for Mozilla to be in a position whereby we would support this work)? One option might be to simply merge the two specs (?). |
|
You're asking two (overall) questions in this thread:
IMO today's answer (which we should commit, and like any position, be open to changing when concerns change) : "harmful"
We do not need to answer this "forward-looking" question to answer the first "present-state" question. And this github issue is perhaps not the best place to discuss spec improvement suggestions. It's likely better to file a separate issue noting the above concerns on the spec's repo and link to it here (rather than discuss the issue in this repo), which would also better encourage spec advocates to participate in the discussion. Aside: regarding the analogy "Similarly to Payment Request API and Payment Handler API" - the payment "silos" are not actively harming the web, unlike the social media silos. |
|
Hi all, sorry I haven't commented lately. (And note, I'm not part of Mozilla so my opinion is void w.r.t. implementation, but since we're discussing the merits of the specs themselves, I thought I'd participate.)
Agreed.
To be fair, that screenshot is from Apple's proprietary share system, totally unrelated to Web Share. Firefox has a similar share system built right into the browser (sorry this is a screenshot from an old Firefox): You might say these affordances allow the user to easily share into large content silos like Facebook and Twitter. Firefox has a (proprietary) API allowing any service to create its own share target in here, so it's better than Apple which has a fixed list. On Chrome (for Android) we have a similar share button, which shares to any installed app. That does take you away from the Web, into Android land, but it's an open ecosystem there; it's just as easy to share into an email client than into Facebook. So far, this has nothing to do with Web Share. Web Share is merely an API for triggering this UI that already exists in most browsers, and sharing data into any targets the user agent wants to provide (the Web Share spec isn't opinionated about what the targets should be). So whether Web Share is biased towards large content silos is a product of the user agent's choices. Thus, I think Web Share (even ignoring Web Share Target) does more good than harm. To understand this, we have to separate the concepts of "web vs native apps" from "open ecosystems vs content silos". Yes, Web Share without WST does tend to take users away from the web in Chrome's Android implementation (though that wouldn't be true in Firefox, which would presumably use the existing share targets, which are web sites). But your argument here is not about taking users from the web into native applications. It's about encouraging users to share content into vertical silos like Facebook and Twitter. I would argue that Web Share is a net positive because it replaces the status quo, which is this:
(i.e., every web page directing users to a fixed set of targets, typically only the 2--4 big social players) with a generic open-ended API that, at worst, presents the user with the same fixed choice of social services, but at best, allows the user to choose their own service. (At the discretion of the user agent.) Even right now, without Web Share Target standards, Firefox could hook So even while we don't yet have a standard solution for specifying share targets on the web, Web Share is a decentralizing technology, not centralizing.
Thanks. I do very much agree with your goals, and I believe the proposed API furthers those goals. I am not doing this because someone at Google told me we need a share API. I'm doing this because I fundamentally believe in decentralization through user choice of service. So with respect to the above, I would rather not merge the two specs, since the latter is significantly more complex than the former. I am not trying to make the case that "Yes, Part 1 will make things worse but (a possibly-never-to-exist) Part 2 will make things all better." Rather, I think Part 1 will make things better right now, and then Part 2 will make things even better. |
|
@dbaron, unless you have follow up questions, could you kindly evaluate the arguments presented here and deliberate on a position? @martinthomson, could you kindly assign @dbaron to this issue? I don't seem to have rights to do that. |
|
Just a quick note that the Firefox team removed the mentioned proprietary Social API in 2017 (because nobody was really using it and it wasn't fun to maintain): https://www.fxsitecompat.com/en-CA/docs/2017/social-api-has-been-completely-removed/ |
|
We also removed the unsupported registerContentHandler which had some overlap in use-cases too but no other vendor wanted to support it. |
|
I imagine that if there were a standardized way for a web site to announce itself as being able to be used as a sharing service, it would actually eliminate the current fracturing of the experience we currently have, with different browsers using different techniques to offer sharing (if they offer it at all). Certainly it would open up the sharing experience on Apple's browsers (assuming they choose to implement it), which currently cannot be expanded by a web site without a browser extension on Mac (or at all on iOS). |
|
Sorry for the lag in responding here. One initial thought is that I think we should probably list a position both for the Web Share API and for the Web Share Target API, because if we don't list both, a position on one is likely to be misinterpreted as applying to both. I looked at the latter somewhat recently as part of w3ctag/design-reviews#221; the former had a TAG review a while back in w3ctag/design-reviews#179. I'll try to dig in further next week. |
dbaron
added
the
venue: W3C CG
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to mozilla#58, mozilla#27, mozilla#24, and mozilla#19. It also happens to include the first links to caniuse (the "ciuName" field being non-null). Note that activities.py normalized some whitespace in a prior entry added in mozilla#53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
These issues seem worth trying to resolve first, and as part of being more public about that discussion, I'm going to explicitly list them as "under consideration" and reference their issues. This will thus link to #58, #27, #24, and #19. It also happens to include the first links to caniuse (the "ciuName" field being non-null), and first links to bugzilla. Note that activities.py normalized some whitespace in a prior entry added in #53. (I should figure out why it's always adding a space at the end of the line, but that's a separate issue. Until then, I'd rather keep the file matching the way activities.py regenerates it rather than having to hand-edit every time to avoid changing those lines.)
|
So briefly coming back to this after a while of not looking at it:
|
|
Does this diminish the value of the URL we show in the location bar as the subject/target that is shared? The primary interface in browsers is based on using what is shown in the location bar. Giving sites the ability to share something else reduces the incentive to set window.location to something usable. Not a big concern, but maybe worth considering the secondary effects. |
|
Not sure who these questions are phrased at (me?). I'm not a Mozillian but I can answer on behalf of Google:
I think we see a fairly consistent desire from websites to put share UI inside the site client area, not just rely on use of the browser UI for sharing. Currently this practice of in-client-area share buttons encourages large content silos like Twitter and Facebook, since the site will only show buttons to share to specific, popular destinations. Web Share allows the user agent to show any share destination, which can be tailored to the user's preferences (e.g., hook into Firefox's in-browser share system).
WST is registered in the manifest, and has nothing per se to do with service workers. It just opens a browser page at a specific URL (constructed by inserting query parameters into a URL). We're aware of certain specific use cases where people want to catch these shares programmatically in a service worker, rather than forcibly having a page opened. That's something we want to address separately in the launch event, something we also discussed at TPAC in the SW WG. |
Add some text steering folks to Bugzilla to ask about or contribute to the Firefox support for a specification, per #27 (comment)
|
@gobengo please use the Bugzilla bug for Web Share API to check for info about Firefox support in particular. In this case it looks like it was implemented in Firefox 71: https://bugzilla.mozilla.org/show_bug.cgi?id=1312422 (also linked from the standards-position dashboard entry via the wrench). You can also check the corresponding MDN page (also linked from the dashboard entry) if you only wanted to check whether or not Firefox (or another browser) supports it: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share#browser_compatibility For Web Share Target API, I checked https://mozilla.github.io/standards-positions/#web-share-target and it also has a wrench icon link to its corresponding Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1476515 (Originally published at: https://tantek.com/2022/032/t1/) |
|
Thanks Tantek. I reactivated a bugzilla account to post on this issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1312422#c44 I think that the bugzilla bug linked to from this dataset for Web Share API does not correspond to implementation of the Web Share API in all Firefox supported browsers, but just to some initial work ('DOM implementation') that set the stage. |
Add some text steering folks to Bugzilla to ask about or contribute to the Firefox support for a specification, per #27 (comment)
Add some text steering folks to Bugzilla to ask about or contribute to the Firefox support for a specification, per mozilla#27 (comment)
zcorpan
added
duplicate
and removed
venue: W3C CG
|
I have split this into separate issues (see #1087): |
|
Web Share Target API was already separate, see #176. |
zcorpan
added
position: positive
venue: W3C CG
|
@saschanaz Oops, thanks! Let's keep the original issues as the canonical ones. |
|
Re-opening this due to unresolved comments (mix of negative, neutral, positive), and substantial new information about the UI that current implementations are presenting as of 2025. Previously, previously, previously:
And a minor unaddressed concern from Martin:
Since those concerns were written (validated by screenshots at the time showing centralized content / social media silos in browser UI), it appears browsers (perhaps OS updates) no longer show such silos in browser UI for “share” (as of 2025). Need updated screenshots. (Originally published at: https://tantek.com/2025/028/t1/) |
tantek
added
venue: W3C
|
Note that since this issue was opened, the spec was adopted by the Web Apps WG, and published as a W3C Recommendation as of 2023-05-30: Updated latest editor’s draft AKA
Dropping label "position:positive" until we resolve the conflicts between negative, neutral, and positive historical comments upthread, to avoid miscommunicating our position (which is semi-orthogonal to any implementation status — see individual bugs cited above for that). (Originally published at: https://tantek.com/2025/028/t2/) |
zcorpan
moved this from Unscreened
to Needs proposed position
in standards-positions review
Request for Mozilla Position on an Emerging Web Specification
Other information
Currently behind a flag in Chrome as an "origin trial".
This specification defines 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.
The text was updated successfully, but these errors were encountered: