fix(parser): don't drop @container/@layer at-rules on CSS parse
The browser CSS parser only recognised nestable at-rules (@container,
@layer, ...) when the CSSOM reported a falsy rule `type`. That happened
to work in Chrome, where the legacy `CSSRule.type` is `0` for newer
at-rules, but engines that expose a real numeric type (jsdom reports
`17` for `CSSContainerRule`) fell through every branch and the whole
rule — selectors, styles and condition — was silently discarded.
Detect nestable at-rules via `getNestableAtRule` regardless of the
numeric `type`. `getNestableAtRule` already matches only when the rule's
`cssText` starts with the exact `@<name>`, so normal style/keyframe
rules are unaffected. The parsed condition keeps the container name and
its query separated by a space, so the exported CSS is valid again
(e.g. `@container somename (min-width: 300px){...}`).
Fixes#5969
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Initial setup for custom code parser
* Update ParserHtml
* Move methods
* Up
* Move utils
* Fix tests
* Up sanitize
* Up domToParsedNode
* Up fragment node
* Remove node cloning
* Convert ParserHtml to class
* Convert ParserCss to a class
* Update Custom CSS/HTML docs
* Always use isParsedNode if available
* Update API
* Update docs for isParserNode
* Add support for nested CSS rules
* Update undo test
* Cleanup resolutions and TS config
* Update jest
* Normalize tests for the latest jsdom version
* Parse nested CSS rules
* Add hidden test for @page at-rule
* Fix VuePress build
* Up CI nodejs
TowyTowy
Artur Arseniev
tomekcz
nanto_vi, TOYAMA Nao
mohamed yahia
Daniel Starns