-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web Share API review #554
Comments
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:
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. |
The WebApps WG would welcome your review of the Web Share API specification. This is a delayed request for review after the FPWD was published in December 2019.
We hope you can complete your review before the end of October 2020, but if this timetable does not work for you, please let us know.
If you have comments or concerns with the Web Share API specification, please file them as issues on the Web Share API repository, and use the tag-needs-resolution label [3].
Thank you.
@marcoscaceres @mgiuca @ewilligers
The text was updated successfully, but these errors were encountered: