Removed navigator.canShare.

[mgiuca]

Resolves #5.

[mgiuca]

I'm not super convinced we don't want this (since there may be situations in which the UA sometimes has targets, sometimes does not). But best to start small and add later if necessary.

@benfredwells

[benfredwells]

Seems good to me, but I can't merge it :(

[marcoscaceres]

The proposal here is not very idiomatic and would cause it to behave unlike any other DOM API. Share targets can be added asynchronously at any point in time (via the OS or via a share target being registered). As such, this should probably not appear and disappear from one turn of the event loop to another (or change from a function to undefined. The problem is that navigator.hasOwnProperty("share") would return true even if set to undefined ... which would be confusing).

We could work on the assumption that there is always at least 1 share target: the UA share box itself... For instance, Safari has "Add to Reading List" and "Add To Bookmarks" as persistent share targets. Other UAs might inform the user about adding share targets or might simply allow the user to cancel.

[marcoscaceres]

@benfredwells, I've added you to the list of collaborators and made @mgiuca repo admin. Matt, please feel free to add additional collaborators.

[mgiuca]

We could work on the assumption that there is always at least 1 share target: the UA share box itself... For instance, Safari has "Add to Reading List" and "Add To Bookmarks" as persistent share targets. Other UAs might inform the user about adding share targets or might simply allow the user to cancel.

Yes, we did decide on that assumption on Tuesday. (The rationale for removing canShare was to assume that there's always at least 1 share target on any supported platforms.)

I did not mean to imply that navigator.share would come and go dynamically as share targets are added and removed. If we want to support that, we should have a dedicated canShare. I just thought we had decided that you'll generally either always have at least 1 share target, or not support the API at all (on any given platform). In that case feature detection is sufficient.

I don't mind either way. I just thought we could remove canShare and add it back if we find a good reason to.

[marcoscaceres]

I did not mean to imply that navigator.share would come and go dynamically as share targets are added and removed. If we want to support that, we should have a dedicated canShare. I just thought we had decided that you'll generally either always have at least 1 share target, or not support the API at all (on any given platform). In that case feature detection is sufficient.

Ah, ok. But the current phrasing is confusing then, as it makes it sounds like the browser might take the API away at arbitrary moments.

[mgiuca]

Ah, ok. But the current phrasing is confusing then, as it makes it sounds like the browser might take the API away at arbitrary moments.

Fair enough. Reworded.

[marcoscaceres]

Apologies, but the problem here remains. The current reading is that the user agent would implement ".share", but it would return "undefined". This would mean that the following would return true:

var x = "share" in navigator; // true, even though it's "undefined"

Worst case, .share should be nullable - but if there is no share target at all in the platform, the user agent would not implement the API at all.

There are examples of this in the platform: for instance, Android's marketplace APK size restrictions prevent Firefox from shipping ES's Intl on Android (because it would add like 30+ megabytes to Firefox) - hence, Firefox does not ship that API on Android - and thus Intl is not implemented at all, even though it's shipped on Desktop.

[mgiuca]

Hmm, didn't realise that there's a difference between being undefined and not being defined. (bleh) Is it sufficient to say "navigator.share SHOULD NOT be present"? I'm not sure what you mean by "Worst case, .share should be nullable".

[mgiuca]

Updated.

[mgiuca]

Update: We've had some discussion on the Chrome side and it looks like it isn't great to have navigator.share be missing on some platforms but not on others. In particular, we haven't found any precedent for this: lots of mobile-only APIs (e.g. Accelerometer, Vibration, Screen Orientation) still exist on Chrome's Desktop implementations but don't do anything meaningful.

I think there's a case to be made that, in dglazkov's words: "the API surface does not change from OS to OS, but the way it responds does."

This means we probably do want canShare so we can do more targeted feature detection. It's possible we'll also want to be able to detect whether there are targets that support particular types of content, like images, so canShare would become more useful.

[PaulKinlan]

This similar thing is being discussed on the notifications spec as well whatwg/notifications#81 and whatwg/notifications#80 - for things that are not available on the platform should the notification object expose it and how should we do it.

[benfredwells]

I think the navigator.share === undefined approach is attrictive when you consider other browsers. If we have canShare I can imagine this code:

if (navigator.canShare !== undefined && navigator.canShare()) {
  navigator.share(...);
}

or even, for the paranoid:

if (navigator.canShare !== undefined && navigator.canShare()) {
  if (navigator.share !== undefined) {
    navigator.share(...);
  }
}

instead of

if (navigator.share !== undefined) {
  navigator.share(...);
}

[dglazkov]

The key issue, I think, is that you end up having different varieties of a Web platform across implementations, and that seems bad for predictability. I sympathize with @benfredwells syntactic elegance argument. If there was a way to specify that share is may return undefined in WebIDL, I would be okay with that.

[dglazkov]

@RByers, to put this on Predictability folks' radar.

[mgiuca]

@dglazkov

you end up having different varieties of a Web platform across implementations, and that seems bad for predictability

The way I see it, if you consider a method being undefined or not as a "variety", then you're always going to have two different varieties of every API until all browsers implement on all platforms, and all users update to the newer versions of those browsers:
a) undefined
b) defined

And developers always have to deal with those two "varieties".

If we add a canShare method, now there will be three varieties of the API:
a) undefined
b) defined, but canShare returns false
c) defined, and canShare returns true

In effect, forcing developers to deal with more possibilities. (I believe this is @benfredwells point.)

If there was a way to specify that share is may return undefined in WebIDL, I would be okay with that.

Do you mean a call to share() returns undefined, or that share itself is undefined? We can specify that in WebIDL but I don't think we should have to. Any API can implicitly be undefined simply by the fact that a given browser hasn't implemented it yet. If we consider Chrome Windows and Chrome Android as two different browsers, then we simply have an API that is implemented on one browser, but not on another. Which is something developers have to deal with anyway.

[dglazkov]

Thanks for explaining. I see that canShare adds, not reduces the API surface entropy. I've made peace with the idea that, on some platforms, we may be not implementing some partial interfaces (like the partial Navigator here). @RByers does that make sense to you?

[RByers]

Sorry for the delay (still getting caught up after TPAC).

Thanks for explaining. I see that canShare adds, not reduces the API surface entropy. I've made peace with the idea that, on some platforms, we may be not implementing some partial interfaces (like the partial Navigator here). @RByers does that make sense to you?

Yes, in cases like this I agree it's better for developers if they have to reason only about "does this API exist or not".

Just to make sure I understand, we're talking only about variations between platforms (Android vs. Windows) here, right? Not something more dynamic? The challenge we've had in other contexts (eg. TouchEvents API, origin trials) is that it's difficult for us to make expressions like 'share' in navigator be both dynamic (something whose result can change after process startup) and efficient.

If there's no such need for dynamism here, then I agree we should definitely just leverage normal feature detection patterns around the existence of properties.

[mgiuca]

@RByers Yes, this is (at the moment) just a static "is this supported on my platform". We would reconsider adding canShare if we needed anything dynamic (such as "are there any apps installed that handle this request").

[mgiuca]

So we are launching this on the origin trial without canShare. It seems we have consensus on this from above. I'm going to close this out so our explainer/interface docs match what we've implemented so far.

[marcoscaceres]

sounds good.