Add support for CSS nesting - #522
Conversation
Signed-off-by: Jens Oliver Meiert <jens@meiert.com>
Signed-off-by: Jens Oliver Meiert <jens@meiert.com>
|
Is this codebase different from validator/validator@c5abf58 ? |
validator/validator is an HTML validator. This repo covers the W3C CSS validator. |
|
It appears that CSS validator also exists in HTML validator: I wanted originally to create an issue against whatever is running at https://validator.w3.org/, but when creating a "CSS issue" at https://github.com/validator/validator/, it redirects into this repo Where do I need to create an issue to fix CSS-in-HTML validation at https://validator.w3.org/ ? |
|
Thanks a lot for this PR, I will merge this then add more patches to support things that were in what I was working on. |
|
Nice :) What is the process for this fix to land in downstream https://github.com/validator/validator and go live at https://validator.w3.org ? |
Absolutely!—glad this helped! |
CC @sideshowbarker 🙂 |
Revert the css-validator parts of c5abf58 and cb96dc6, so that css-validator/ matches upstream’s validator-nu branch again. Upstream now has its own support for both — w3c/css-validator#522 adds CSS nesting, and later upstream commits add @scope — and the commits that follow bring that in.
Add support for CSS nesting to the CSS parser. From w3c/css-validator#522. Signed-off-by: Jens Oliver Meiert <jens@meiert.com>
Add block detection and nesting resolution to the CSS parser. From w3c/css-validator#522. Signed-off-by: Jens Oliver Meiert <jens@meiert.com>
3 participants
Resolves #431 and #481. The CSS from #521 validates as well (the issue refers to a commit in validator/validator).
Disclosure: I felt free to tackle this knowing this is a much-requested feature; as I’m at the deeper end here, I used Claude Code to help with some of the work. That said, I take responsibility for the code presented with this PR.
What’s supported (CSS3 profiles and up; CSS 2.1 and earlier still report nesting as an error):
&anywhere in a compound, relative selectors (> a,+ p,~ p), selector lists, and deep nesting@media,@supports, and@layernested in style rules, with declarations directly inside&in pseudo-class arguments (:is(),:not(),:where(),:has(),:nth-*(… of S))Rules and declarations are told apart as in CSS Syntax: a
{before the next;or}means a nested rule. Nested rules are resolved against their parents and emitted as flat rules, so the cascade, conflict checks, and the “Valid CSS information” output work as before (ul, ol { li { … } }becomesul li, ol li). Where substituting the parent would change the meaning,&becomes:is(parent).@containerand@scopearen’t supported by the validator in general; nested ones are reported as “Unrecognized at-rule,” as at the top level.Also fixed along the way:
[x]div { … }was valid; this also affected&div)@layernever closed its at-rule in the output model, so every following rule was printed inside the layer;@layer a, b;statements now print like@importNotes:
CssParser.javawas regenerated with JavaCC 7.0.13, because thejavaccsubmodule (7.0.4) can’t parse the current grammar (diamond operator). 7.0.13 reproduces the currentCssParser.javabyte for byte, so most of that diff is generated.bugs/3633*.cssnow report 1 error instead of a duplicated 2, which is what the test notes call ideal. Their XML entries use thecss2profile, which is unchanged.css3svgandcss21profiles. The only change is the one above. The new nesting tests all pass withant autotest. The 3general.xmltests that fail (loops/loop1.css,loops/loop2.css,at-rule/valid.css) fail onmainas well.Tests: w3c/css-validator-testsuite#4 (the submodule pointer is left to update).