Explain why canShare exists at definition.

[scheib]

It's an unusual pattern to see .foo() and canFoo(). The specification would benefit from text or a note explaining why the canShare method exists. (As would all downstream documentation).

From a brief bit of research reading spec, MDN, and a few 'how to' articles, it isn't clear why web developers should go through the extra machinations. Perhaps it is explained, but not near the definition. There is, however, a note discussing feature detecting 'share'.

If share() is present, there is a reasonable expectation that it will work and present the user with at least one share target. Clients can use the presence or absence of this method to determine whether to show UI that triggers its use.

Perhaps canShare is to enable an optimization to not prepare data for sharing until we know if it is possible. Likely many developers will prefer the code simplicity of feature detecting .share() and attempting the share. This optimization doesn't seem necessary for many applications. If there's a reason that wouldn't be a good idea, or if it specifically wouldn't work, the specification should explain why.

[ewilligers]

Another motivation was version detection. For example, early implementations have no support for file sharing. A web app might want to hide or disable a "Share" button on user agents that do not support file sharing.

[scheib]

Thank you. I'm sorry that as a reader I see https://github.com/w3c/web-share/pull/177/files adding a definition of the algorithm and behavior, but not the explanation of why canShare exists or the motivation to use it instead of share.

[marcoscaceres]

@scheib sorry, seems I forgot to include the commit that explains things 🤦‍♂️. It's here for you as part of #177:
93e175d

[scheib]

Thank you, this resolves the issue well!