Taken up at Tokyo F2F.

Thanks! Our feedback:

• Can we have the feedback from the origin trial when it's available?
• The API looks good
• We would like to see how extended service-specfic metadata could be included in the share action (eg twitter related accounts)

No further feedback so we don't think we need to open any issues on your repo, and thank you very much for bringing this to us so early in the process!

Hi Andrew,

Thanks. I didn't actually get CC'd on this until now. It also seems we inadvertently opened a second TAG review on this: #179 so discussion is continuing there.

Specification draft is now up: https://wicg.github.io/web-share/

In response to your questions:

Can we have the feedback from the origin trial when it's available?
The M56 Origin Trial results is still the best set of feedback we have. We also published the M57 results but they didn't really add any new info.

We would like to see how extended service-specfic metadata could be included in the share action (eg twitter related accounts)

I'm not exactly sure what this means, but I'm not really keen to add anything service-specific to the share action, because the point is that any service should be able to handle the request.

Having broad concepts that apply more to certain services is OK, for example Twitter's intent API includes a "hashtags" field which we could put into the ShareData in the future. That's a little bit Twitter-specific but is sufficiently generic that it can be used (or ignored) by other services as well.

Hi Matt, thanks for the response. My concern about service specific metadata arises from use cases where services would retain a strong incentive to get developers to implement a custom share button rather than integrate with the web share api.

For example, twitter offers lots of metadata properties on a share, including tagging other accounts, which is obviously definitionally service specific. I'm aware of several large orgs that use that feature, because it helps them build engagement around their own account.

So there are a number of options here. There could be an option to pass namespaced custom properties into the share action, which would make sense to only one share service. Or some "borderline" cases could be absorbed into the standard as you suggest. Or maybe there's another solution or one isn't necessary. I just wanted to flag the potential for this to be a brake on adoption.

Thanks for the explanation. Interesting.

By "tagging other accounts" do you mean they would make it automatically insert "@mytwitterhandle" into the composed tweet? Why not just put that into the text?

I'm tempted to say we should just wait and see if people state this as a reason against adoption, instead of pre-empting it by including the feature. It kind of violates the whole "the sender doesn't care about what the target is" philosophy.

If we do want to implement this, we could just open the floodgates to let you put any fields in the dictionary, and deliver them all to the recipient. Then specific services could define their own fields. But then that effectively lets individual apps define de facto web standards without going through any standards process. So I would be very careful about adding such a thing.

Hi @w3ctag/tag, could you kindly please close the TAG issues in the tracker for Web Share? (all of which were addressed) They are currently preventing us from moving to the Web Share API to CR. Link to each issue is provided via the dashboard:

https://www.w3.org/PM/horizontal/review.html?shortname=web-share

AFAICT all the issues were already closed as well as the TAG review. Seems odd that the label would be making closed issues show up, but I removed the labels from the closed issues.

Thanks @plinss!

@plinss, sorry, the ones that need to be closed are actually these ones:

w3ctag/tracking-issues#21
w3ctag/tracking-issues#20
w3ctag/tracking-issues#19
w3ctag/tracking-issues#18