Repository navigation
Improve checks for invalid CSS function names #4048
Description
Currently, it's possible for users to define functions whose names differ from reserved names only by case, such as EXPRESSION() or URL(). These functions can't be invoked normally, because the logic for function calls is case-insensitive, but unlike their lowercase equivalents they're not forbidden at definition-time. We should make the invalid function name check case-insensitive to deprecate and eventually forbid these names.
Edit: I've updated the title to broaden the scope here a bit. There are a number of improvements to be made to this check, mostly in the form of loosening it for cases that aren't (or are no longer) of real concern.
- Proposal ([Function Name] Add proposal #4053)
Deprecation
- Tests ([Function Name] Add tests sass-spec#2109)
- Implementation ([Function Name] Implement changes dart-sass#2731)
- Documentation ([Function Name] Document sass-site#1527)
- Update canonical spec ([Function Name] Mark as accepted and flush to spec #4186)
Final Changes
Activity
[-]Forbidden CSS function names should be case-insensitive[/-][+]Improve checks for invalid CSS function names[/+]nex3 commentedon Jul 30, 2025
Hi @ugwudev, and thanks for reaching out! Implementing a deprecation isn't too difficult, but there are a few steps:
In this repo, add the new deprecation to
spec/deprecations.yaml. This is the shared source of truth for which deprecations exist, their names, and their documentation.In the https://github.com/sass/dart-sass repo, symlink this repo into
build/sass, then rundart run grinder deprecations. This will add a deprecation enum entry for the new deprecation you just added. Then find the place where the deprecation should be emitted and emit it.In the https://github.com/sass/sass-spec repo, run
npm run sass-spec -- --dart=<path/to/dart-sass> --interactiveto run all the language tests. If it finds any language tests that are failing (likely because they're now using deprecated behavior), it'll give you an interactive menu for how to update them.Write some new tests to cover your new deprecations.
Send out the pull requests. For the dart-sass pull request, make sure you include links to the other two pull requests so that it knows to run those tests; for the sass-spec pull request, make sure you include
[skip dart-sass]since those tests are being run in the dart-sass repo anyway.You can see #4045, sass/sass-spec#2051, and sass/dart-sass#2540 as examples of PRs that add a new deprecation.
nex3 commentedon Aug 4, 2025
I'm not sure what you mean by "a
@debugdeprecation", but generally deprecations should be emitted wherever it's easiest to detect the issue. The logger object that handles deprecations is piped throughout the codebase. In the case of function names, I'd expect the deprecation to be emitted in the parser (lib/src/parse/stylesheet.dart).nex3 commentedon Aug 29, 2025
It sounds like you might have this backwards: you should have a symlink from the
sassrepo todart-sass/build/language. If that's still not working, try pasting yourdart run grinder deprecationsoutput here and I'll see if I can figure out what's going on.The
@functionrule is parsed by the_functionRule()function.nex3 commentedon Sep 3, 2025
It's common that you'll get merge conflicts as the main branch evolves. How to handle them depends on how you're using Git, but if you're using the CLI you can use
git pull origin mainto pull in the latest version of the upstream code base. This will print out a list of conflicting files which you can then fix one-by-one in a text editor.[Function Name] Implement changes
[Function Name] Implement changes
[Function Name] Implement changes
[Function Name] Implement changes
[Function Name] Implement changes
[Function Name] Implement changes
[Function Name] Implement changes (#2731)