TPAC planning and specification status report

[LJWatson]

TPAC will be virtual this year. W3C is finalising the details but it is likely there will be events for the whole W3C community during the week of 26 to 31 October (as originally planned), with WG able to organise their own meetings in/around that week.

There are two things we need you to do:

1. Let @marcoscaceres and I know before 17 July if you want meeting time to talk about your specification.
2. Post a specification status report before 30 September.

The specification status report should include:

• What progress has your spec made in the last 12 months?
• Is anything blocking your spec from moving to CR?
• If yes, what is your plan to unblock it and do you need any help?

Your specification status report from 2019 is at #121

[marcoscaceres]

Hey Share Folks! would be great to meet up and chat during TPAC to iron out any last issues and scope out anything else we might want to add over the next year (or if we are ready to go to CR).

I added a cal entry for the following times:

Melbourne (Australia - Victoria) | Wednesday, 28 October 2020 at 8:00:00 am
San Francisco (USA - California) | Tuesday, 27 October 2020 at 2:00:00 pm
London (United Kingdom - England) | Tuesday, 27 October 2020 at 9:00:00 pm | Tuesday, 27 October 2020 at 21:00:00

See your time at meeting planner.

Let me know if that works... otherwise, we can set up a Doodle or something.

[marcoscaceres]

What progress has your spec made in the last 12 months?

• Check transient activation after sharePromise (Check transient activation after sharePromise #183)
• Reject non-http URLs for url member (Reject non-http URLs for url member #174)
• Use a sequence for files (User a sequence for files #170)
• Introduce "web-share" feature policy (Introduce "web-share" feature policy #166)
• BREAKING CHANGE: make share() consume user activation (BREAKING CHANGE: make share() consume user activation #137)
• Add the ability to share files (Add the ability to share files #133)
• Initial take on Security/Privacy self-review (Initial take on Security/Privacy self-review #150)
• Accessibility considerations (Accessibility considerations #146)

Is anything blocking your spec from moving to CR?

The canShare() method has been shown to be somewhat unfit for purpose, with one implementer reluctant to ship it (Gecko). Some alternatives are in the works - in particular #184 or some variant of it (Gecko is experimenting with canShareType()).

Concerns have also been raised about sharing arbitrary files with share targets. At least one implementer would like to see the list of possible types restricted by expanding #185. The proposal is to only allow certain file extensions / mime type combinations.

Less of a priority, adding support for blobs #182 (files can wrap blobs, so kinda already works). Other issues remain, but they are mostly editorial.

Not blocking: but a proposal was made by @adactio to come up with a declarative solution #176, but at least two implementers have said that now is not the appropriate time to add such a thing to the spec (we need more implementation experience + and also to see how devs use the API) - but it would be great to see a proposal incubated at the WICG.

- If yes, what is your plan to unblock it and do you need any help?

Plan is just to keep collaborating to reach consensus on suitable solutions to the issues raised above.

[marcoscaceres]

Closing as this is for last year's TPAC.