WHATWG Wiki - User contributions [en]

Install-less Service Workers

2015-07-14T22:30:07Z

Ehsan:

This is a proposal for allowing usage of service workers without installing them. This will be useful for APIs such as Push, and Background Sync. FetchEvent will not be dispatched to such service workers. The script source for these service workers wouldn't be cached locally (except for perhaps in the HTTP cache as all other resources) so every time that the UA wants to spin up one of these, it needs to potentially load it from the network.

== Changes to Service Workers ==

The RegistrationOptions dictionary would need to be extended like this:

<pre>dictionary RegistrationOptions {
USVString scope;
boolean install;
};</pre>

The [http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#register-algorithm Register algorithm] would need to be modified around step 4.2 to treat install: false specially by not doing nothing when an existing worker has been installed for that scope (and maybe reusing it, that requires more thought) and skip running the [http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#update-algorithm Update algorithm].

Furthermore, the current definition of [http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker-registration registrations] heavily depends on the workers being installed, and we would need to perhaps have a parallel list of workers that have been registered in this new mode. We need to figure out how to treat the intersection of these two sets.

We can probably expose a new readonly boolean attribute on ServiceWorkerRegistration like installed to be able to return a ServiceWorkerRegistration object from register() for the install: false case that will have slightly different semantics (such as never having an installing and waiting worker, its update() method not doing anything, else) but this will have the nice property that the [https://w3c.github.io/push-api/#extensions-to-the-serviceworkerregistration-interface Push API hooks] and the similar can work with both types of workers.

Install-less Service Workers

2015-07-14T18:01:11Z

Ehsan: Created page with "This is a proposal for allowing usage of service workers without installing them. This will be useful for APIs such as Push, and Background Sync. FetchEvent will not be disp..."

This is a proposal for allowing usage of service workers without installing them. This will be useful for APIs such as Push, and Background Sync. FetchEvent will not be dispatched to such service workers.

== Changes to Service Workers ==

The RegistrationOptions dictionary would need to be extended like this:

<pre>dictionary RegistrationOptions {
USVString scope;
boolean install;
};</pre>

The [http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#register-algorithm Register algorithm] would need to be modified around step 4.2 to treat install: false specially by not doing nothing when an existing worker has been installed for that scope (and maybe reusing it, that requires more thought) and skip running the [http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#update-algorithm Update algorithm].

Furthermore, the current definition of [http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#dfn-service-worker-registration registrations] heavily depends on the workers being installed, and we would need to perhaps have a parallel list of workers that have been registered in this new mode. We need to figure out how to treat the intersection of these two sets.

We can probably expose a new readonly boolean attribute on ServiceWorkerRegistration like installed to be able to return a ServiceWorkerRegistration object from register() for the install: false case that will have slightly different semantics (such as never having an installing and waiting worker, its update() method not doing anything, else) but this will have the nice property that the [https://w3c.github.io/push-api/#extensions-to-the-serviceworkerregistration-interface Push API hooks] and the similar can work with both types of workers.

Sharing

2014-08-13T16:55:35Z

Ehsan:

Figuring out sharing for the web.

== Actors ==

* End user
* User agent
* Items that can be shared (share item)
* Place that has items to share (share source)
* Place items can be shared with (share destination)

(Could potentially merge share source and share item.)

== Use cases ==

Brief: E wants to share I (image, URL, ...) from S (The New Yorker, xkcd, ...) on D (Twitter, Facebook, Pocket ...)

Longer: End users want to share http://www.boston.com/bigpicture/2014/07/conflict_continues_in_gaza.html from The Big Picture with their preferred social network or private database.

== Idea ==

* Provide UI to share the current URL
* Provide API to add share destination
* Provide new "overlay browsing context" to display share destinations when sharing is initiated (ideally using limited space so the share source remains functionally useful on desktop)

=== Share UI ===

Revamp user agent bookmarks. Bookmarks are about sharing the current URL with yourself. We could generalize that concept to share that URL with Twitter, Pocket, or any other service that gets itself added as share destination.

=== Overlay browsing context ===

* Displays e.g. Twitter's compose tweet dialog loaded from https://twitter.com/share (conceptual URL)
* Protects against spoofing so other sites cannot imitate Twitter's login dialog there
* Ideally provides some way to do transparent backgrounds to enable the kind of UI Pocket would like, without compromising on security
** To expand on that, sharing UIs will typically involve accepting the user's authentication info, one risk here is to overlay a UI on top of the page in a way that doesn't make it obvious to the user that the UI is not part of the page itself. Once a user is trained to accept these types of subtle overlays, evil.com may try a phishing attack by rendering the Pocket UI inside its own frame and asking for the user's auth info.

== Constraints ==

* A secure origin (TLS) is required to be a share destination. Requiring a secure origin for a share source seems like too much of a burden.
* Share nothing other than the share item and the origin of the share source with the share destination (e.g. no DOM access).

== registerProtocolHandler() ==

* Open-ended scheme names does not work when UI requires knowledge about its scheme name. ("Can Gmail handle 'mailto'?" vs "Can Gmail handle email links?")
* Replaces the current browsing contexts or spawns a new one. No overlay
* Limited to sharing things that can be expressed through a URL

== TODO ==

* Scope of share items: restrict to URL of the share origin for now?
** (ehsan) I think we may need to handle more than just the URL, for example if the user wants to share an embedded image/video on a site.
* Share destination registration UI
* Share UI: user-agent-initiated or share-source-initiated?
** (ehsan) the web has pretty much settled on the latter at this point.
** (ehsan) are we talking about telling the share source about the user's preferred search service or get them to call an API which does this opaquely?
* (ehsan) Should we integrate [http://opengraphprotocol.org/ OGP annotations]?
* (ehsan) Sharing providers typically want to be able to show their UI *before* the sharing happens too.

== Resources ==

* Paul Kinlan on Web Intents: http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0023.html
* Jonas Sicking on Web Activities: https://wiki.mozilla.org/WebAPI/WebActivities/LessonsLearned
* http://webintents.org/
* https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities
* http://www.imore.com/sharing-ios-8-explained

Sharing

2014-08-11T20:56:02Z

Ehsan: /* TODO */

Figuring out sharing for the web.

== Actors ==

* End user
* User agent
* Items that can be shared (share item)
* Place that has items to share (share source)
* Place items can be shared with (share destination)

(Could potentially merge share source and share item.)

== Use cases ==

Brief: E wants to share I (image, URL, ...) from S (The New Yorker, xkcd, ...) on D (Twitter, Facebook, Pocket ...)

Longer: End users want to share http://www.boston.com/bigpicture/2014/07/conflict_continues_in_gaza.html from The Big Picture with their preferred social network or private database.

== UI speculation ==

There's a couple of parts that might require interaction with the user:

* Adding share destinations
* Initiating sharing: this could be either through an API or as on iOS through dedicated chrome UI
* Displaying share destination after sharing is initiated: e.g. through a special overlay browsing context. In case of Twitter this might require almost the entire screen (on mobile). In case of Pocket this would not require much UI at all in the simple case.

== UI idea ==

Revamp user agent bookmarks. Bookmarks are about sharing the current URL with yourself. We could generalize that concept to share that URL with Twitter, Pocket, or any other service that gets itself added as share destination.

== Constraints ==

* A secure origin (TLS) is required to be a share destination. Requiring a secure origin for a share source seems like too much of a burden.
* Share nothing other than the share item and the origin of the share source with the share destination (e.g. no DOM access).

== registerProtocolHandler() ==

* Open-ended scheme names does not work when UI requires knowledge about its scheme name. ("Can Gmail handle 'mailto'?" vs "Can Gmail handle email links?")
* Replaces the current browsing contexts or spawns a new one. No overlay
* Limited to sharing things that can be expressed through a URL

== TODO ==

* Scope of share items: restrict to URL of the share origin for now?
** (ehsan) I think we may need to handle more than just the URL, for example if the user wants to share an embedded image/video on a site.
* Share destination registration UI
* Share UI: user-agent-initiated or share-source-initiated?
** (ehsan) the web has pretty much settled on the latter at this point.
** (ehsan) are we talking about telling the share source about the user's preferred search service or get them to call an API which does this opaquely?
* (ehsan) Should we integrate [http://opengraphprotocol.org/ OGP annotations]?
* (ehsan) Sharing providers typically want to be able to show their UI *before* the sharing happens too.

== Resources ==

* Paul Kinlan on Web Intents: http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0023.html
* Jonas Sicking on Web Activities: https://wiki.mozilla.org/WebAPI/WebActivities/LessonsLearned
* http://webintents.org/
* https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities
* http://www.imore.com/sharing-ios-8-explained