Moving back to upstream `selectors`? about lightningcss HOT 2 OPEN

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 #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.

from lightningcss.

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

from lightningcss.