Re: Are web components *seriously* not namespaced?

[Henri Manson]

I created a prototype of this idea on github:
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/README.md by
forking the original webcomponents.js project.
It contains a working example of this concept. Below the content of the
README.md file:

This fork of webcomponents.js enhances Document.registerElement so that the
options argument can contain a 'namespace' property which contains an XHTML
namespaceURI e.g. http://mansoft.nl/big-blue-button so you can put a custom
element in another namespace than http://www.w3.org/1999/xhtml, which is
the default when no namespace is specified. The custom element registry is
now a 2 dimensional lookup table. First the namespaceURI is looked up and
then the localname of the custom Element. An example usage can be found at
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-test-polyfill-ce.xhtml
Here two custom elements are defined with the same name 'bigbutton'
(without dashes) but with different namespaces "
http://mansoft.nl/big-red-button"; and "http://mansoft.nl/big-blue-button";.
When webcomponents.js is build you can test this file on a browser not
natively implementing Document.registerElement e.g. Firefox An important
change is to no longer use the HTML-specific onclick functions etc. but the
generic DOM AddEventListener pattern. The registration of the components
using the extra 'namespace' property is done in
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/bbb-component.js
and
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-component.js
The example component 'Big Red Button' is based on a webcomponent sample
from Robin Berjon's presentation 'Distributed Extensibility: Finally Done
Right?' on XML Prague 2014.

When this will be implemented in the official Custom Element specification
it will be possible to polyfill XHTML with for example XForms by
implementing each XForm component using custom components. Or MathML.

I'll be happy to hear your comments and suggestions.

RE: Normative references to Workers.

[Domenic Denicola]

From: Xiaoqian Wu [mailto:xiaoq...@w3.org] 

> If the spec is still changing frequently, indeed it isn't a good idea to 
> publish another CR… but the WebApps WG needs to clearly tell the community 
> that the 2012 CR should be considered obsolete. 
>
> I’d suggest that we publish a WD for Workers, which adapts to the current 
> changes and revise the 2012 CR. The community is encouraged to refer to 
> either the WHATWG version or the new WD. 

The best way to accomplish this may be to do the same as has been done with 
other specs, and either redirect to the original source document (e.g. as has 
been done with Fullscreen) or replace the WD and CR with NOTEs directing 
visitors to the source document.

Re: Normative references to Workers.

[Xiaoqian Wu]

> On 22 Sep, 2015, at 1:35 am, Anne van Kesteren  wrote:
> 
> On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow  wrote:
>> On 9/21/15 5:54 AM, Ms2ger wrote:
>>> Why?
>> 
>> I think the rationale was mentioned in
>> .
> 
> Ms2ger made a valid point. Workers is actively being updated (I
> submitted two PRs the other day, more to come). If you don't want to
> get out-of-sync you won't get to REC in the foreseeable future. It
> therefore is likely a waste of time for someone to volunteer to
> copy-and-paste text that is unstable.
> 

Thanks for explaining the situation :)

If the spec is still changing frequently, indeed it isn't a good idea to 
publish another CR… but the WebApps WG needs to clearly tell the community that 
the 2012 CR should be considered obsolete. 

I’d suggest that we publish a WD for Workers, which adapts to the current 
changes and revise the 2012 CR. The community is encouraged to refer to either 
the WHATWG version or the new WD. 

—
xiaoqian

> 
> -- 
> https://annevankesteren.nl/
> 

Re: Normative references to Workers.

[Anne van Kesteren]

On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow  wrote:
> On 9/21/15 5:54 AM, Ms2ger wrote:
>> Why?
>
> I think the rationale was mentioned in
> .

Ms2ger made a valid point. Workers is actively being updated (I
submitted two PRs the other day, more to come). If you don't want to
get out-of-sync you won't get to REC in the foreseeable future. It
therefore is likely a waste of time for someone to volunteer to
copy-and-paste text that is unstable.


-- 
https://annevankesteren.nl/

Re: Normative references to Workers.

[Arthur Barstow]

On 9/21/15 5:54 AM, Ms2ger wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 11:05 AM, Xiaoqian Wu wrote:

If it helps, I’d like to prepare a Workers draft to revise the
previous CR, and schedule the publication ASAP (hopefully 22 Sep).
The goal is to synchronise with the upstream, to document the
changes since the previous CR and to identify the "at risk”
features.


OK, thanks (and please let me know when a draft CR is ready and then 
I'll start a CfC to publish it).



Why?


I think the rationale was mentioned in 
.


-AB

Re: RfC: Service Workers

[Arthur Barstow]

Please use the Version 1 branch for this review: 



On 9/21/15 7:27 AM, Arthur Barstow wrote:
[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG 
(public-web-mobile), W3C Chairs (chairs),  Review Announce list 
(public-review-announce), Geolocation WG (public-geolocation) ]


The Editors and active contributors of Service Workers intend to 
publish a Candidate Recommendation soon (details below). Consequently, 
this is a Request for Comments by the WebApps group to seek wide 
review of the latest version of the spec:




The open issues for Version 1, and the spec's version history are [1] 
and [2], respectively.


If you have any comments, we prefer you submit them as Github issues 
[3]; otherwise, please send your comments to the public-webapps list 
[4] using a Subject: prefix of "[serviceworkers]".


-Thanks, AB

[1] 


[2] 
[3] 
[4] 


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.

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

RE: Service Workers

[Jungkee Song]

Thanks for the RfC, Art.

To make it clear (although there's no difference as of now), Service Workers 1 
(https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/) is the 
branch based on which we'd like to request a CR publication.

Thanks,
Jungkee

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: Monday, September 21, 2015 8:28 PM
> To: public-webapps
> Subject: RfC: Service Workers
> 
> [ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG (public-
> web-mobile), W3C Chairs (chairs),  Review Announce list (public-review-
> announce), Geolocation WG (public-geolocation) ]
> 
> The Editors and active contributors of Service Workers intend to publish a
> Candidate Recommendation soon (details below). Consequently, this is a
> Request for Comments by the WebApps group to seek wide review of the
> latest version of the spec:
> 
> 
> 
> The open issues for Version 1, and the spec's version history are [1] and
> [2], respectively.
> 
> If you have any comments, we prefer you submit them as Github issues [3];
> otherwise, please send your comments to the public-webapps list [4] using
> a Subject: prefix of "[serviceworkers]".
> 
> -Thanks, AB
> 
> [1]
>  e+milestone%3A%22Version+1%22>
> [2] 
> [3] 
> [4] 
> 
> 
> 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.
> >
> > 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

RfC: Service Workers

[Arthur Barstow]

[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG 
(public-web-mobile), W3C Chairs (chairs),  Review Announce list 
(public-review-announce), Geolocation WG (public-geolocation) ]


The Editors and active contributors of Service Workers intend to publish 
a Candidate Recommendation soon (details below). Consequently, this is a 
Request for Comments by the WebApps group to seek wide review of the 
latest version of the spec:




The open issues for Version 1, and the spec's version history are [1] 
and [2], respectively.


If you have any comments, we prefer you submit them as Github issues 
[3]; otherwise, please send your comments to the public-webapps list [4] 
using a Subject: prefix of "[serviceworkers]".


-Thanks, AB

[1] 


[2] 
[3] 
[4] 


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.

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

Re: Normative references to Workers.

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 11:05 AM, Xiaoqian Wu wrote:
> If it helps, I’d like to prepare a Workers draft to revise the 
> previous CR, and schedule the publication ASAP (hopefully 22 Sep). 
> The goal is to synchronise with the upstream, to document the
> changes since the previous CR and to identify the "at risk”
> features.
> 

Why? What are you trying to achieve that makes doing that a good use
of your time (and the time of everyone else in that toolchain)?

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV/9PeAAoJEOXgvIL+s8n2AokIAJH7kcGJmSrNKn/SyKBeNGPH
INFwRIw8vReupG7g5rrIc9fErpV/4r/15dcpz87Z7IRx1S+Ne/6IrGWLnJMx+Boc
x7mvGW7rPm2Jqnq9S6s8W2n+QpFa4Z+2haznH+p9divt79Y7fYIhtwrcNEYc6z6c
Hs7wcfWGrCd7DbpjjMS2RdKls0YEHOkfu6VIi9wqn+DpFLXOYVgSg8CbiDtaRJiy
Pnjh3GuAl8hizW30tCUFF+YlELxQmRL6ojWnSb6AcD//VB+dFS3Jtf8QFEeL934i
kDQjyR1TUFlz7t3Xa409D48qpyG7/5s580KX5gRq0mFU8IhtzP2BNKMLgfgqvyw=
=X2q+
-END PGP SIGNATURE-

Re: Normative references to Workers.

[Xiaoqian Wu]

> On 16 Sep, 2015, at 8:17 pm, Arthur Barstow  wrote:
> 
> On 9/16/15 4:47 AM, Mike West wrote:
>> Note that this is an issue that's going to come up for a number of WebAppSec 
>> specs (see 
>> https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8 
>> , 
>> for instance (and that spec also needs a few things that are missing from 
>> W3C's HTML, but are present in WHATWG's)). What I hear so far on this thread 
>> is that we should simply reference the WHATWG version of those specs, which 
>> seems like a reasonable thing to do.
> 
> Yes, for the scenario you mention, I agree with you.
> 
> The grey area is when a feature is defined by both a W3C WG and WHATWG. 
> Because of the consortium's Patent Policy, I suspect consensus among 
> consortium members is to use the W3C spec for normative references. However, 
> if the W3C spec is no longer actively maintained by a WG, then normatively 
> referencing a WHATWG spec would (IMHO) be appropriate and I think the 
> Normative Reference Policy [NRP] supports such a scenario.
> 
> In this specific case, I don't believe anyone has committed to actively 
> maintain W3C Web Workers. As such, WebApps - do we have a volunteer? Please 
> let us know (or send me private e-mail if you prefer).

If it helps, I’d like to prepare a Workers draft to revise the previous CR, and 
schedule the publication ASAP (hopefully 22 Sep). The goal is to synchronise 
with the upstream, to document the changes since the previous CR and to 
identify the "at risk” features. 

Thanks.

--
xiaoqian

> 
> -Thanks, AB
> 
> [NRP] 
> 
> 
>> 
>> -mike
>> 
>> --
>> Mike West mailto:mk...@google.com>>, @mikewest
>> 
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, 
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
>> Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>> 
>> On Tue, Sep 15, 2015 at 7:31 PM, Mike West > > wrote:
>> 
>>The "Upgrade Insecure Requests" specification[1] references the
>>WHATWG HTML spec for the
>>"set up a worker environment settings object" algorithm[2], as the
>>Web Workers Candidate Recommendation from May 2012[3]
>>substantially predates the entire concept of a "settings object",
>>and because the WHATWG is the group where work on Workers seems to
>>be being done.
>> 
>>This referential choice was flagged during a discussion of
>>transitioning the Upgrade spec to CR, where it was noted that the
>>Web Workers editor's draft from May 2014 does contain the
>>referenced concept[4].
>> 
>>It seems appropriate, then, to bring the question to this group:
>>does WebApps intend to update the Workers draft in TR? If so, is
>>there a path forward to aligning the Workers document with the
>>work that's happened over the last year and a half in WHATWG?
>>Alternatively, does WebApps intend to drop work on Workers in
>>favor of the WHATWG's document?
>> 
>>It would be helpful if we could get some clarity here. :)
>> 
>>Thanks!
>> 
>>[1]: https://w3c.github.io/webappsec/specs/upgrade/
>>[2]:
>>
>> https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
>>[3]: http://www.w3.org/TR/workers/
>>[4]: https://w3c.github.io/workers/
>> 
>>--
>>Mike West mailto:mk...@google.com>>, @mikewest
>> 
>>Google Germany GmbH, Dienerstrasse 12, 80331 München,
>>Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
>>Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
>>Elizabeth Flores
>>(Sorry; I'm legally required to add this exciting detail to
>>emails. Bleh.)
>> 
>> 
> 
>