Re: [w3ctag/design-reviews] Web Share API review (#554)

In review with @plinss during our Cork virtual f2f, we are assume that this is the respective explainer that goes with that design review. 

In general we like the concept and approach to it. The following is a summary of some concerns we have.  We will also open as individual issues in your repo.

The current API exposes a single global share promise and it is unclear why this is needed. This global appears to clutter the navigator space while also being exposed as a return parameter. Can we remove it?

Is the share method better exposed as an interface between navigator and the share method (e.g. Share interface) making it easier to integrate with the share target API or any other share capabilities. From extensibility and future-proofing point of view, having such interface will save us from having to add more methods to navigator in the future. 

The contents of the ShareData dictionary is tied to the File API. This makes it a requirement to implement File API before you can have Share API. A user might want to share an image directly from their camera feed which is still a blob. It would be good to explore exposing lower level block in addition to a file.

One more observation close to the file vs blob comment is about exposing capability to share different formats. Examples of such extensibility could sharing a Calendar, vCard, and other structured data that can be useful to users - JSON of user contact info for example.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/554#issuecomment-697550980