Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cssom] Merge Constructable Stylesheets spec into CSSOM spec #3433

Closed
rakina opened this issue Dec 12, 2018 · 21 comments
Closed

[cssom] Merge Constructable Stylesheets spec into CSSOM spec #3433

rakina opened this issue Dec 12, 2018 · 21 comments
Labels

Comments

@rakina
Copy link
Member

@rakina rakina commented Dec 12, 2018

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
Copy link
Member

@astearns astearns commented Dec 12, 2018

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.

Loading

@emilio
Copy link
Collaborator

@emilio emilio commented Dec 14, 2018

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.

Loading

@tabatkins
Copy link
Member

@tabatkins tabatkins commented Dec 14, 2018

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.

Loading

@astearns
Copy link
Member

@astearns astearns commented Dec 14, 2018

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.

Loading

@rakina
Copy link
Member Author

@rakina rakina commented Dec 17, 2018

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?

Loading

@astearns
Copy link
Member

@astearns astearns commented Dec 17, 2018

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.

Loading

@domenic
Copy link
Collaborator

@domenic domenic commented Dec 17, 2018

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.

Loading

@astearns
Copy link
Member

@astearns astearns commented Dec 17, 2018

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.

Loading

@tabatkins
Copy link
Member

@tabatkins tabatkins commented Jan 11, 2019

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.

Loading

@astearns
Copy link
Member

@astearns astearns commented Jan 11, 2019

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.

Loading

@emilio
Copy link
Collaborator

@emilio emilio commented Jan 12, 2019

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.

Loading

@marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Dec 13, 2019

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.

Loading

@rakina
Copy link
Member Author

@rakina rakina commented Jan 13, 2020

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

Loading

@emilio
Copy link
Collaborator

@emilio emilio commented Jan 13, 2020

That is ok for me.

Loading

@rakina
Copy link
Member Author

@rakina rakina commented Feb 19, 2020

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.

Loading

@astearns
Copy link
Member

@astearns astearns commented Feb 19, 2020

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

Loading

@marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Feb 21, 2020

@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 :)

Loading

@astearns
Copy link
Member

@astearns astearns commented Mar 12, 2021

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?)

Loading

@rakina
Copy link
Member Author

@rakina rakina commented Apr 19, 2021

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.

Loading

@mfreed7
Copy link

@mfreed7 mfreed7 commented May 10, 2021

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.

Loading

@mfreed7
Copy link

@mfreed7 mfreed7 commented May 22, 2021

Loading

@emilio emilio closed this in #6304 Jun 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
8 participants