[worklets] Merge the worklets spec into HTML?

[domenic]

https://drafts.css-houdini.org/worklets/

The worklets specification is, at this point, serving as a fairly stable piece of foundational infrastructure for other specifications. However, it's continuously impacted by cross-cutting changes in how HTML defines script fetching, event loops, agents, and globals, as well as Web IDL updates. See, for example, #467, #757, #938, #956, #958, #966, #981, #984, #992, and #998. This is because, along with service workers, worklets is the only other spec on the web platform that defines a new global environment.

Offline, @bfgeek mentioned it's hard for him to find the time to edit the specification. Given that, and the cross-cutting and foundational nature of worklet globals, would it make sense to merge the spec into the HTML Standard?

If the Houdini TF is interested in this, I'd be happy to put in the legwork of moving it over, triaging or moving open worklets issues, and sending pull requests to all the other worklet-using specs to ensure they link to the new definitions.

[AmeliaBR]

I definitely agree that it makes sense to have the core definition of worklets in the same place as the definition of web workers and the window scope, both because it makes sense for authors trying to understand & compare, and for easy maintenance of spec updates.

(I'm not sure why those are defined in HTML, rather than in DOM, but that is at the discretion of those of you maintaining the specs!)

[css-meeting-bot]

The CSS Working Group just discussed [worklets] Merge the worklets spec into HTML?, and agreed to the following:

• RESOLVED: publish new WD of Worklets
• RESOLVED: Hand over worklets to HTML after publishing the D

The full IRC log of that discussion

<dael> Topic: [worklets] Merge the worklets spec into HTML?
<dael> github: https://github.com//issues/1000
<dael> astearns: worklets editors are in favor
<dael> astearns: Makes sense as things change from under worklets it's in same place to be tracked and kept up to date
<astearns> ack fantasai
<dael> fantasai: If ED is newer than latest WD we should publish and than pass off. Gets it into official records
<fantasai> s/than/then/
<dael> astearns: Fair. Anyone know if ED has unpublished changes?
<dael> iank_: What's the benefit of that?
<dael> fantasai: Main is it makes sure this is properly archived. Also bookmarks all work done in CSSWG for patient policy. ED aren't covered at all, but if you publish WD it advances to rec.
<dael> fantasai: It probably won't but I would rather get it into official record. If there is no FPWD than whatever.
<dael> chris: THere is
<dael> fantasai: Then let's put the latest up.
<dael> AmeliaBR: Makes a clean handoff of what work was done under W3C policy. I think handover is cleaner with eq. process but it's a nice stamp of this is where we were at
<dael> fantasai: iank_ you don't have to do it, you can tell chris to
<dael> astearns: chris will you take that on?
<dael> chris: Sure
<dael> astearns: Objections to publish new WD of Worklets?
<dael> RESOLVED: publish new WD of Worklets
<dael> astearns: Obj to move worklets to HTML?
<dael> chris: What part of html makes it to move
<dael> AmeliaBR: web workers are in html
<dael> TabAtkins: Mechanics of globals change. Need to keep worklets consistent
<dael> iank_: Other thing is we have 2 impl of worklets, FF and Chromium
<dael> astearns: Objections?
<dael> RESOLVED: Hand over worklets to HTML after publishing the D
<dael> s/D/WD

[domenic]

Hi folks! Any progress on publishing the WD?

I also noticed that worklets is under the W3C restrictive document license, not the permissive one. That seems problematic for this effort. Is there any way to relicense it?

[svgeesus]

Any progress on publishing the WD?

Yes, it was published on the 8 September
https://www.w3.org/TR/2020/WD-worklets-1-20200908/

[domenic]

Ah, excellent. Any ideas on the licensing issue?

[svgeesus]

By permissive, do you mean the software and document license? I thought CSS was using that for all specs. Yes, from the charter:

This Working Group will use the W3C Software and Document license for all its deliverables.

[domenic]

Yes. Hmm, so what is the process for getting Worklets corrected to use that license? Currently it links to https://www.w3.org/Consortium/Legal/2015/doc-license

[frivoal]

Given the charter, I believe that the fact that this document was published under the W3C Document License rather than the W3C Software and Document License is a mistake. I suspect that we just fix it by correcting the editor's draft, and then updating the TR publication as well, and that the charter's mandate for the W3C Software and Document License empowers us to do that without further ceremony.

Just to double check, @wseltzer, am I missing something?

[svgeesus]

I agree with @frivoal and suspect this was a copy and paste error in bikeshed boilerplate files, so should also be fixed there.

[svgeesus]

Okay fixed on /TR

The bikeshed template for joint CSS and TAG publications still needs to be fixed @tabatkins I suspect that is why it used the wrong one.

[svgeesus]

Looks like the problem is here and applies to all Houdini specs.

change

<a href="https://www.w3.org/Consortium/Legal/copyright-documents">document use</a>

to

<a href="https://www.w3.org/Consortium/Legal/copyright-software-and-document">permissive document use</a>

[domenic]

Worklets now exist in HTML, at https://html.spec.whatwg.org/multipage/worklets.html ! And #1011 works on updating this repository accordingly.

Other nice to haves, which I'll reopen this issue to track:

• Make https://drafts.css-houdini.org/worklets/ server-side redirect to https://html.spec.whatwg.org/multipage/worklets.html , instead of the client-side redirect created in Reflect worklets moving to HTML #1011

• Make https://www.w3.org/TR/worklets-1/ and https://www.w3.org/TR/worklets/ redirect to https://html.spec.whatwg.org/multipage/worklets.html . (Maybe @sideshowbarker can help with that?)