[w3ctag/design-reviews] Web Share Target API (#221)

Hello TAG!

I'm requesting a TAG review of:

  - Name: Web Share Target
  - Specification URL: https://wicg.github.io/web-share-target/
  - Explainer, Requirements Doc, or Example code: https://github.com/WICG/web-share-target/blob/master/docs/explainer.md (please ignore examples; there are updated examples in the spec)
  - Tests: None
  - Primary contacts: @mgiuca, @owencm

Further details (optional):

  - [x] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/design-principles/)

You should also know that...

- This is a companion to the [Web Share](https://wicg.github.io/web-share/) spec that was the subject of [this previous TAG review](https://github.com/w3ctag/design-reviews/issues/179). But the two specs are independent (other than sharing a common IDL data structure).
- This is highly coupled to the [Web App Manifest](https://www.w3.org/TR/appmanifest/) spec, but I think it will remain as a separate spec, at least initially.
- There is a prototype implementation in Chrome on Windows, Linux, Chrome OS and Android.
- There is a demo site/app [here](https://wicg.github.io/web-share-target/demos/sharetarget.html).

Questions for the review panel:

- The biggest open issue is [this](https://github.com/WICG/web-share-target/issues/25): we should catch errors in the URL template at manifest parse time. This is tricky because it essentially means we need to resolve the URL template against the manifest URL at parse time, before substituting the parameters. This isn't well defined because the URL template *is not a URL* and so can't have the URL parser applied to it. Not sure how to proceed; [my solution](https://github.com/WICG/web-share-target/pull/28) was to make a dummy parse by substituting the empty strings in, but it has issues noted in that pull request.
- Related, we have [identified a problem](https://github.com/WICG/web-share-target/issues/30) if the template includes placeholders in path segments, like `"/foo/{text}."`, if the text supplied is ".." then it would be a path escape. Not sure how to resolve this; escaping doesn't help because the URL Standard explicitly says that "%2e%2e" also means parent directory. The easiest solution is to simply prevent placeholders from appearing before the '?' (so they have to be in the query or fragment).

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
  - [x] leave review feedback as a comment in this issue and @-notify @mgiuca

Thanks and feel free to post any follow-up discussion questions here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/221