Will this concept be ported into W3C's Worker document as well? https://www.w3.org/TR/workers/ points to this repository for issues, so...

This still isn't in https://www.w3.org/TR/workers/.

@chaals, @wseltzer, @plehegar: can y'all help me figure out who to poke about the fact that that document is a little less than a year out of date? I'll note that it was only updated then because I poked y'all about the even more out of date 2012 CR on a call. There seems to be a pattern of neglect here since y'all removed Workers from the W3C version of HTML.

Ping? :)

Ping?

@travisleithead do you know if we have any plan to find a replacement editor for workers? Looks like Hixie isn't maintaining that anymore

I'm working on it. Watch this space - and sorry for the delays.

@chaals: Perhaps this is something some set of folks could chat about at TPAC? The current setup doesn't seem to be working.

https://www.w3.org/TR/workers/ is now over a year old.

https://www.w3.org/TR/workers/ is now over a year old.

And we expect it to be updated shortly. The new editor has been working on moving the spec to bikeshed, which introduces a bit of a delay.

I'm glad you're looking at it.

I worry a bit that the conversion will have similar issues to the HTML conversion way back when, increasing the difficulty of bringing in patches. Have y'all put together a plan for updates? The ad-hoc mechanism doesn't seem to be working very well.

Ad-hoc is probably not a good idea in the long run, yes. I'm going to have to talk with some of the whatwg folks to see a better way forward, but for the meanwhile - at least for workers - adhoc is good enough as it isn't a overly dynamic spec.

You can see the work in progress here: https://w3c.github.io/workers/

Upstream patch intakes will come the moment I'm done making the current draft vis-a-vis with the 1 year old draft.

You could just not fork the spec and treat the WHATWG spec as the standard instead...

@chaals, @plehegar, @wseltzer:

https://www.w3.org/TR/workers/ is now over a year old.

And we expect it to be updated shortly.

It's been ~7 months since we last talked about this, and https://w3c.github.io/workers/ hasn't been touched since (literally: the last commit was on September 27th when I pinged this thread).

I'd gently suggest that the strategy of rewriting the WHATWG spec using a different engine, and backporting patches in an ad-hoc manner isn't working.

It's been ~7 months since we last talked about this, and https://w3c.github.io/workers/ hasn't been touched since (literally: the last commit was on September 27th when I pinged this thread).

Yeah, I'm entirely to blame for this. (Been busy with work that pays the bills, unfortunately W3C isn't one of them) I'll get to this after 5/8 EST. Apologies.

@cynthia: I don't mean to throw you under a bus. I don't really think this situation is your fault, and I don't think you doing some sort of heroic rewrite in a week is a long-term solution. If the working group wants to keep the structure it has set up, it needs to have a sane maintenance strategy. It's pretty clear that such a strategy doesn't exist for Workers, and hasn't for years.

It looks like a few things got ported over in June (Thanks, @cynthia!), but "CSP list" wasn't one of them. I didn't dig into the patch to see what other differences might be lurking, but there are at least a few (for instance: the document defines a close() method on WorkerGlobalScope that isn't in the WHATWG document, and isn't implemented in either Chrome or Firefox). :)

Since @LJWatson is preparing a TPAC agenda for the WG, perhaps it would be reasonable to discuss y'all's maintenance of the Workers spec in general? The year and a half of pings followed by reassurances followed by pings in this issue here does not fill me with confidence for that document's suitability as an implementation target (/cc @chaals, @plehegar, @wseltzer).

@mikewest Yeah, most of it is me to blame. I'll get to the CSP bit in the next round of merges - trying to find out what is interoperable and what is not to clean the mess up.

@mikewest last time we looked at worker, we got blocked by lack of support for sharedWorker. Maybe it's time to pop that one up the stack.

@cynthia: As I noted earlier in the thread, I still don't mean to put blame at your feet. Given the group's decision to split Workers out of the HTML spec, I still think it's the group's responsibility to have a sane maintenance strategy for the document since porting patches becomes quite a bit more difficult.

@plehegar: The current draft does contain shared workers, and I'm fairly sure they're implemented in both Blink-based browsers and Firefox. I do hope interop issues won't be blockers for y'all.