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.

Hi TAG,

I was surprised to see a new review for this API. Note that we had a TAG review for Web Share three years ago (#179) and resolved issues from it. The API is now fully shipped in multiple browsers, so making breaking changes (even if agreeable) would not be possible.

Looks like the four issues were raised separately. 1 was a misunderstanding. 3 and 4 are possible extensions that should not result in breaking changes, so we can keep those open. 2 I have closed because I think this is the sort of agreeable change that it is just not practical to make at this late stage in the API's life.

Can we close this review, or should we wait until the above issues are all resolved as well?

Just supporting @mgiuca position regarding the renames + definitely open to having a discussion about supporting blobs.

@LJWatson, @mgiuca and @marcoscaceres thank you for opening this review and reminding us of the previous review of this work. @torgo and myself did another pass looking at the current spec and previous TAG resolution. What we could offer at this point are the following three options:

1. Close this review based on the previous resolution (https://github.com/w3ctag/design-reviews/issues/179#issuecomment-306526807) and the fact it is shipping in most major browsers.
2. Treat this as a delta review in preparation of moving your spec on the REC track
3. Treat the review as new (unlikely)

As an aside, we want to underline that this is a great example of a success story. This feature was successful going from an early inception, incubation, and TAG review to being addopted in the WebApps WG as FPWD with great privicy and security section, and attracting multiple implementations - great job and congratulations.

As to this review, please let us know what your preference is and we'll move forward accordingly.

I think "2. Treat this as a delta review in preparation of moving your spec on the REC track" sounds good.

Hi folks - after reviewing the delta we feel we have nothing to add a this time. We're happy to close this.