On Tue, Jun 21, 2016 at 1:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> That's the benefit of splitting the feature into sharing outward only to
> native to start. For that we can show the native share dialog/sheet that
> users would see in Android or iOS apps. To allow Web->Web or Native->Web
> sharing it'll require something different.
I think the big difference is that iOS and Android offer a button at
the system-level. It's not really triggered by a site, but by the user
invoking browser (system) UI. This is also the UI Safari on a Mac
offers.
Right, lots of browsers are now offering Share buttons at the browser UI level. Web Share is (at the first stage) about essentially giving web pages a programmatic API to trigger that Share button.
That was the kind of UI our work from back in 2014 tried to target as
well (and Firefox has experimented with too).
Does this still exist in Firefox? I see
this documentation but don't see the share button in my Firefox 47 UI (on Linux).
This proposal requires integration from both those that have something
to share and from those it can be shared with, which seems much
trickier to successfully deploy.
It shouldn't require integration from "those that can be shared with"; with just Web Share, we'll require participation from "those that have something to share" but the targets will be automatically available: on Android as a system intent, on iOS as a system share, on Windows 10 UWP apps could share to the system contract, etc. On OSes that don't have a native share system, the browser can still provide its own sharing system (as Mac Safari does, and Firefox
apparently did or does). We don't want to specify what the UI is or exactly how the browser should let users pick the target (i.e., whether there's a hardcoded list or whether the browser lets the user add arbitrary sites; whether the browser automatically posts to Twitter as Safari does or whether it just opens a new
twitter.com tab pre-filled with the message). We just want a way to trigger the share of some site-specified content.
This won't necessarily make sense on all browsers and platforms, but as a progressive enhancement feature, it doesn't have to (as long as we get agreement from many browser vendors; we don't want this to be a feature specific to one vendor).
I'm also not convinced it gives the
right user experience as you lose the button that users are getting
familiarized with.
I'm not proposing to remove the browser-ui-Share buttons. This would be an alternative mechanism for sharing.
In a way this proposal is still Ballista, except now share is part of
the API names, rather than a parameter.
Yes, it is. We aren't trying to distance ourselves from Ballista, but rather break off small workable pieces of the
original Ballista proposal. We had a lot of discussions where we were told "you aren't going to be able to standardize the Ballista API in a single go; focus small." So we did.
One casualty of that is that the API itself got less generic. For those who didn't see the original Ballista proposal, it was something like this:
navigator.actions.performAction({verb: 'share'}, {...})
and now it is
navigator.share({...})
This implies that if we do continue to build more of these Ballista capabilities after Web Share, they may end up all being separate top-level methods instead of a more generic "performAction" or similar. But just focusing on Web Share as the proposal stands today, it doesn't make a whole lot of sense to have the generic method. I think if we went with the generic performAction, library authors would likely end up providing similar abstractions over it anyway.
--
https://annevankesteren.nl/