Service Workers 1 and Nightly

[Jungkee Song]

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1]. 

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
 - Register/Update/Unregister of a service worker registration
 - Handle fetch events
 - Fetch and Cache resources
 - Manage service worker clients
 - Communicate between a client and a service worker
 - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.

For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/


--
Jungkee Song
Samsung Electronics

[Bug 29136] New: Keyboard events should specify their target when more than 1 document exists

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29136

Bug ID: 29136
   Summary: Keyboard events should specify their target when more
than 1 document exists
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: UI Events
  Assignee: gary...@google.com
  Reporter: jyass...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
  Target Milestone: ---

https://w3c.github.io/uievents/#event-type-keydown defines Event.target as
"focused element processing the key event or if no element focused, then the
body element if available, otherwise the root element". However, "the body
element" and "the root element" aren't uniquely defined within a UA. The UA may
have multiple browsing contexts, and each browsing context can contain multiple
documents.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Service Workers 1 and Nightly

[Arthur Barstow]

On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.


Hi Jungkee, All,

Thanks for this update!

Regarding the publishing plan above, the latest process document 
includes an expectation that before a CR is published the spec "has 
already received wide review" [1]. Although the group is free to 
determine the wide review "requirements" (see [2]), it can be useful to 
publish a new WD and use that WD as the basis of the wide review. It 
would also be possible to use an ED (perhaps a static snapshot) as the 
basis for the review. There is also a question about which group(s) we 
explicitly want to ask to review the spec.


What are your thoughts on the document (WD vs. ED snapshot) to use as 
the review?


Which groups do we ask to review? I presume at least TAG and Web Mobile 
IG. Are there others?


-Thanks, AB

[1] 
[2] 



For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/

Re: Service Workers 1 and Nightly

[Jungkee Song]

On Fri, Sep 18, 2015 at 7:56 PM, Arthur Barstow 
wrote:

>
> Regarding the publishing plan above, the latest process document includes
> an expectation that before a CR is published the spec "has already received
> wide review" [1]. Although the group is free to determine the wide review
> "requirements" (see [2]), it can be useful to publish a new WD and use that
> WD as the basis of the wide review. It would also be possible to use an ED
> (perhaps a static snapshot) as the basis for the review. There is also a
> question about which group(s) we explicitly want to ask to review the spec.
>
> What are your thoughts on the document (WD vs. ED snapshot) to use as the
> review?
>

If there's no particular problem, an ED snapshot would be great to avoid
redundant publication preparations. In that case, I'll try to get it well
prepared before we request it.


>
> Which groups do we ask to review? I presume at least TAG and Web Mobile
> IG. Are there others?
>

I presume TAG, Web Mobile IG, WebAppSec (Security standpoint), Geolocation
WG (Geofencing uses SW) would be good. Any other suggestions?


Thanks,
Jungkee


>
> -Thanks, AB
>
> [1] 
> [2] 
>
>

-- 

Jungkee Song