-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
chore: use zimmerframe for CSS analysis/transformation #10482
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
Conversation
|
(note: the diff is more green than red, but that's because of the tests — the AST now contains more granular detail, which means there's a bunch of bigger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@Rich-Harris can you link relevant PRs for the CSS nesting you might create so I can follow along |
Right now, CSS handling lives in its own universe — we parse the
<style>
tag (sloppily), then bludgeon it into shape with classes defined inStylesheet.js
andSelector.js
that both use zimmerframe and reimplement its traversal behaviour. This takes more code and more CPU cycles than just using the same techniques we use everywhere else for analysis and traversal.As I started working on
:is(...)
support I realised it's also a fairly inflexible approach. I therefore intend to remove a lot of the code inStylesheet.js
andSelector.js
in favour of something more harmonious. Right now it looks like more code, but I'm reasonably confident it will end up being significantly less once it's done.No changeset because this is all internal stuff
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint