fix: handle remaining Tailwind v4 scoped CSS cases#1692
Open
rysinal wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
Tailwind CSS v4 support was tracked in #1550 and the follow-up PR #1628 was released in 1.0.0-rc.30. That PR fixed the
@layerparsing path, but there are still two scoped CSS parser cases that make Tailwind v4 output invalid in child apps.In a real micro-app integration using
@micro-zoe/micro-app@1.0.0-rc.30, styles were still missing after upgrading because Tailwind v4 emits CSS that includes:@property --tw-* { ... }.This also matches the currently open #1690 report, where the failing Tailwind class contains an arbitrary gradient value:
group-hover:bg-[linear-gradient(180deg,transparent_60%,rgba(0,_0,_0,_.6)_93%)].Root cause
CSSParser.matchAtRule()does not recognize@property. When scoped CSS parses Tailwind v4 output, the parser falls through to the normal style-rule path and can incorrectly scope@propertyas if it were a selector. The resulting CSS is invalid, so browser-side style application diverges from direct child-app access.formatSelector()currently splits selector lists with a regular expression that treats every comma as a selector separator. That works for simple selector lists like.a, .b, but it is not safe for Tailwind v4 / modern CSS output where commas can appear inside::is(...)/:where(...)/:has(...)arguments..grid-cols-\[minmax\(0\,_1fr\)\].linear-gradient(...)and nestedrgba(...).When those inner commas are split as top-level selector separators, scoped CSS inserts
micro-app[name=xxx]into the middle of one logical selector, causing the corresponding Tailwind rule to stop matching.Changes
@propertyrule parser and handle it like other self-contained at-rules.@property --tw-*.:is()/:has().Why this is separate from #1628
#1628 fixed one Tailwind v4 blocker around
@layerstatement/block parsing and was included in 1.0.0-rc.30. The remaining failures described here are different parser gaps:@propertyis still not recognized as an at-rule.So users on rc.30 can still see missing styles even though #1550 is closed, especially when Tailwind emits arbitrary utilities or registered custom properties.
Validation
npm cinpx jest src/__tests__/source/scoped_css.test.ts --runInBand --setupFiles <temporary Worker mock>WorkerProxyinitialization fails before scoped CSS tests run becausewindow.Workeris undefined.npx eslint src/sandbox/scoped_css.tsnpx eslint --no-ignore src/__tests__/source/scoped_css.test.tsgit diff --checknpm run buildFixes #1690.
Related to #1550 and #1628.