[cssom] Merge Constructable Stylesheets spec into CSSOM spec

[rakina]

The draft spec for Constructable Stylesheets has gotten pretty stable now (just need WICG/construct-stylesheets#69 to land, probably around this week), and we're interested in merging it into the CSSOM specs. @emilio as editor, does this sound good to you? I'll make a PR if it's OK.

Also cc @domenic @tabatkins

[astearns]

I assume this should be in a next-level draft of CSSOM (so we could finish the current level before adding new features). The PR would then just be a diff spec added to the directory.

[emilio]

I see no problem merging it in CSSOM.

Are you or any other Googler interested in maintaining it? Not a great deal but it'd be good to have some of you on the loop, at least as long as Blink is the only implementation.

I'm not familiar of the process to follow here regarding spec levels and such, but @astearns suggestion sounds reasonable to me.

[tabatkins]

Post-merging I'm happy to do continuing maintenance as necessary if @rakina isn't around.

For spec levels, the concern is just that adding new things to an otherwise-stable document reduces our ability to advance it. If the document isn't already in or near an advanceable state, tho, then it doesn't matter and we can just put the new thing in.

[astearns]

CSSOM has been around long enough that I'd like to get SOME level of it to REC. Starting a new level with this new feature would allow us to move anything else that isn't yet stable to the new level and get the current draft into a state where we could advance it.

[rakina]

It looks like CSSOM is currently Level 1, so this should be in Level 2 of CSSOM? Is there anything else currently on that level?

[astearns]

There is nothing else in level 2 yet, so it would be a new draft in a new folder with just this new feature (and an issue noting that it's a diff spec that will eventually have all of the level 1 content added). See Grid level 2 as an example of how you'd set up the draft.

[domenic]

Note that it's not very straightforward to have a diff spec here since most methods and properties of CSSStyleSheet are modified. Our motivation for merging, instead of maintaining a separate spec, was specifically to have a single specification with all the algorithms in one place, instead of two like we have currently. Having two (cssom-1 + cssom-2) is not an upgrade over our current two (cssom + constructable stylesheets).

Would it be acceptable for us to work on a single document editors' draft, which can be referenced for implementers looking to get a holistic idea of what to implement? Of course the chairs/editors are welcome to carve that up into separate specs for W3C process purposes if they'd like.

[astearns]

It isn't a requirement to make the next-level spec a diff spec. That's done mainly for editor convenience. It's perfectly fine to copy all of level 1 into the level 2 doc (updating the cssom-1 links to cssom-2) to get the holistic document you'd like to work with. It's just more work for the editors to make sure any future edits to cssom-1 are correctly applied to cssom-2 as well.

[tabatkins]

Since the W3C is exploring "living documents" (per last year's TPAC), can we prioritize putting CSSOM on that track? It, like Typed OM, is the sort of doc that regularly gets smaller edits, rather than large new features, and it's often very important for compat that said edits make it into the document promptly.

Then we dont' have to hem and haw over which level to put a feature in.

[astearns]

I don't see hemming and hawing over spec levels as a bad thing - it's just one way of noting which parts of a spec are farther along than others. If we switch to a living document mode we'd have to do the same hemming and hawing over whether to mark a section stable.

I don't have a big preference on work mode for this spec - I'd prefer to leave it up to the editor or editors (are @rakina or @ericwilligers willing to edit CSSOM with this new feature added?). If there's concern that constructable stylesheets are going to need changes in current CSSOM level 1 text then it may make sense to change level 1 to a living document. But if the level 1 document could safely get to REC without the new feature, I think it would make sense to do that and create level 2 as a living document. But that's just me - I'd prefer to let @emilio and whoever else is actually doing the work choose what to do.

[emilio]

I'd prefer to have a single document to maintain if possible. Backporting fixes between two different documents is not really something I'd enjoy, and seems error-prone / prone to get out of sync quickly.

[marcoscaceres]

Tracking bug on the WICG side: WICG/construct-stylesheets#102 ... looking forward to this graduating out of the WICG :) Please don't forget to fill out the intent to migrate once you are ready to move it over to the CSSWG.

[rakina]

Looks like Mozilla folks have looked into the spec in depth, I guess we should merge this soon (after the recently added open issues are resolved). As it seems like people generally prefer just adding this to CSSOM Level 1, is it OK to do that? cc @astearns @emilio @tabatkins @domenic

[emilio]

That is ok for me.

[rakina]

OK, it looks like the spec are in a good state to merge now pending some smallish changes (and issues like WICG/construct-stylesheets#114 and WICG/construct-stylesheets#118 are probably nicer to solve when we merge). I'll try to do this (unless someone else wants to do it?)

@marcoscaceres, question on Intent to Migrate: it says "Use this as a template to include as an issue in your specification's repository" - does this mean CSSWG's repo?

And for the actual spec move, I'll just move the monkeypatches to the appropriate places (CSSStyleSheet definition, insertRule etc definition), except for "Using Constructed Stylesheets"... maybe I'll just add that after the CSSStyleSheet constructor definition? Not so sure. Suggestions welcome.

[astearns]

For the record, the resolution from the CSSWG to bring this into CSSOM is here: https://lists.w3.org/Archives/Public/www-style/2020Feb/0012.html

[marcoscaceres]

@marcoscaceres, question on Intent to Migrate: it says "Use this as a template to include as an issue in your specification's repository" - does this mean CSSWG's repo?

As long as there has been a resolution, etc. then it's all good for you folks to take it. The template is mostly to help new folks that haven't migrated things before. The CSS WG is very experienced with incubating and producing specs in general that take into consideration privacy, security, accessibility, and l10n issues.

So totally ok with CSS WG taking this, as I know it will be in good hands :)

[astearns]

Am I missing something, or was this move never accomplished? @rakina @emilio can we get this into CSSOM soon?

(and when it happens, could we change s/constructable/constructible/ everywhere?)

[rakina]

Oof, sorry for dropping the ball on this one. Last year I handed off most of my CSS-related work to people more actively working on DOM/CSS now (@mfreed7 and @lilles). Mason and Rune, do you think your team can help here? If not, maybe I can carve some time later this quarter for this.

[mfreed7]

I'm going to (finally!) get to this item. Just to confirm, I'm going to merge this into cssom-1, and not cssom-2, per the resolution.

This'll be my first CSSWG spec PR, so wish me luck.

[mfreed7]

#6304