search

w3c / web-share-target

Web API proposal for receiving shared data
https://w3c.github.io/web-share-target/
Other
191 stars 20 forks source link

Encourage service worker requirement #41

Closed ewilligers closed 6 years ago

ewilligers commented 6 years ago

This was suggested during TAG Review https://github.com/w3ctag/design-reviews/issues/221#issuecomment-376717885

Preview | Diff

raucao commented 6 years ago

I don't understand how "to create reliable user experience" is a reason by itself. A service worker file doesn't magically change the experience, especially in regards to opening a share dialog or anything else related to this spec. No?

ewilligers commented 6 years ago

The user might attempt to share while they are offline. Having a service worker is a signal to the UA that the app developer has taken the offline experience into account. For example, the shared data might be cached, and forwarded when connectivity is restored.

raucao commented 6 years ago

Then it's a bad signal imo, because the presence of a service worker does not inherently mean that the app works offline. FWIW, I find it to be an equally bad signal for install-worthiness in Chrome.

So a share target is never supposed to be an online(-only) web app, correct?

ewilligers commented 6 years ago

So a share target is never supposed to be an online(-only) web app, correct?

Correct, we suspect that will lead to a bad user experience if the network is unreliable.

mgiuca commented 6 years ago

I tend to agree with @skddc.

This change stems from a comment in the minutes of the TAG meeting between myself, @ewilligers, @slightlyoff and @dbaron:

"We should add non-normative text encouraging user agents to require a service worker, to create a reliable user experience."

I'm not really sure what the background of this is. My thoughts are:

slightlyoff commented 6 years ago

While a SW might not be a "strong signal" in the sense that it doesn't indicate that the entire site works offline, UAs can (and should) require non-no-op handlers for the Share Target event (likely onfetch in this design) as well as verifying that the URL provided in the target returns something when requested (similar to the additional "works offline" checks that Chrome will be putting in place for PWA installability.

None of this needs to be normative, however, but the spec should note as much non-normatively.

mgiuca commented 6 years ago

UAs can (and should) require non-no-op handlers for the Share Target event (likely onfetch in this design) as well as verifying that the URL provided in the target returns something when requested

The beauty of the current Web Share Target design is that it doesn't require a fetch event, launch event, or even a Service Worker at all. By framing this as a form submission (a GET or POST request), it decouples it from the SW spec. Of course, we're designing it so that sites can improve the experience by using a SW, but there is no intrinsic dependency from WST to SWs.

(Furthermore, UAs will likely tie WST registration to app installation, which will require a SW, but that is orthogonal as well.)

I don't think it's helpful to non-normatively "require" a SW to use WST. As I said above, it doesn't make sense to recommend certain UA behaviour non-normatively. This should either be a normative SHOULD, or be added as a note to say you can tie WST registration to app installation, and not explicitly say this requires a SW (the latter being my preference).

ewilligers commented 6 years ago

I have changed this PR to add the service worker to the "Examples of registration strategies that user agents can employ"

mgiuca commented 6 years ago

lgtm