Moving back to upstream selectors?

[nicoburns]

Development on the Servo project has been picking up recently, and one of the things we're looking at is improving the maintenance of it's crates (including selectors which now lives in https://github.com/servo/stylo) and trying to merge back forks and pool development effort back into the original crates.

I am wondering:

• What changes has lightningcss made to selectors?
• What would it take to get lightningcss back on upstream selectors? (and would you be interested in doing this)?
• Would you be interested in helping to maintain upstream selectors?

selectors is a little complicated than some crates because upstream is actually Mozilla's Firefox repository (currently still using mercurial), but we have / are putting in place a process for coordinating with Gecko developers and syncing changes with Gecko.

[devongovett]

I'd love to do that. The reasons for the fork were:

1. selectors was using an out of date version of cssparser. I think that's been updated now, but differing versions could still happen in the future.
2. Implementing new selector features before they are implemented in browsers or the standards process is finished. One of the reasons people use lightningcss is to compile new CSS features so they work in browsers that don't support them yet. CSS nesting and :has were the main ones so far, but those are now officially supported. However, in the future, I might need a way to add other features before they are implemented in Firefox. That is sometimes possible via the custom PseudoClass/PseudoElement traits but not always.
3. Serialization. LightningCSS supports serde to serialize all of its rules in order to implement plugins and other features. I have added serde support for all of the selector features.
4. Support for some non-standard selectors. Lightning CSS needs to be able to parse and preserve some commonly found non-standard features that browsers would throw away. These are implemented behind a flag. See Support parsing special selector syntax (::deep, ::v-deep, etc…) #495 for some context. Not sure how that could be supported.

If you have any ideas on whether some of these could be supported, either up stream or otherwise via extension, I'd love to make it work.

[nicoburns]

@emilio Would you be willing to accept such changes (appropriately feature flagged if necessary) into upstream selectors?