Skip to content
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 #170

1 of 3 tasks
owencm opened this issue Apr 20, 2017 · 5 comments
1 of 3 tasks

Web Share API #170

owencm opened this issue Apr 20, 2017 · 5 comments


Copy link

@owencm owencm commented Apr 20, 2017

Hello TAG!

I'm requesting a TAG review of:

Note that this has been available for three releases of Chrome experimentally. Our Intent to Experiment thread is here:!msg/blink-dev/zuqQaLp3js8/5V9wpRWhBgAJ

Some of our findings from the experiment are available here:!topic/blink-dev/rgIpGcOyDKI

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]
Copy link

@torgo torgo commented Apr 27, 2017

Taken up at Tokyo F2F.

Copy link

@triblondon triblondon commented Apr 27, 2017

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!

Copy link

@mgiuca mgiuca commented Jun 2, 2017

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:

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.

Copy link

@triblondon triblondon commented Jun 2, 2017

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.

Copy link

@mgiuca mgiuca commented Jun 5, 2017

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.

@triblondon triblondon removed their assignment Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants