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

Yes, if we went with the Service Worker approach, we side-step the entire issue of URL template syntax, since it's coming in through a JavaScript object (essentially it would be a [ShareData](https://wicg.github.io/web-share/#sharedata-dictionary) object from Web Share). Initially, we were considering these two approaches in parallel, but we stopped considering the Service Worker approach a long time ago, for a number of fairly compelling reasons:

1. The URL template approach does not require a Service Worker at all. While it's a nice carrot to convince people to make a SW, it isn't really necessary, and this just slows adoption of WST.
2. The URL template approach can be implemented into existing share services with a single line in the manifest, and no code changes. For example, we just emailed Twitter a single line to add to the manifest and the next day, [it was there](http://mobile.twitter.com/manifest.json) and Twitter was a working Web Share Target (because they already had an endpoint URL that receives a share in the query parameters). Integrating into a SW is a more significant engineering investment.
3. While the SW allows you to do things like receive a share without opening a new window/tab, this is almost always something you want to do anyway.
4. The URL template approach fits neatly into the [Service Worker navigate event](https://docs.google.com/document/d/1jWLpNEFttyLTnxsHs15oT-Hn8I81N0cwUa3JjISoPV8/edit) proposal which I made last year. Instead of adding a new event to SW for WST, we can do the same thing by catching a launch event with the WST data in a URL.

Basically, simplicity trumps flexibility. I'd rather stick with the URL approach.

Also (and this shouldn't be a particularly strong argument when considering a web standard, but I'll say it), we have working implementations on Chrome for both mobile and desktop, as well as websites like Twitter that have implemented it.

-- 
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#issuecomment-363992775