Breaking Change: Function Names

This small breaking change forbids user-defined functions whose names overlap with plain CSS function names that have special syntax, even if they’re not lowercase. It also removes special parsing for function calls that has special syntax unnecessarily.

User-Defined Function NamesUser-Defined Function Names permalink

This change will forbid users from defining functions named URL, EXPRESSION, or ELEMENT, or the same names with any combination of uppercase and lowercase letters.

The fully-lowercase version of these names was already forbidden. Function names in CSS are case-sensitive, though, so in order to be fully CSS-compatible Sass needs to apply special parsing rules even to the uppercase versions. This means that user-defined functions can’t use those names, because the special parsing needs to happen before the language knows which user-defined functions exist.

💡 Fun fact:

As part of this change, some other restrictions on which function names were allowed have been relaxed. Functions with vendor-style prefixes whose names end with -url, -expression, -and, -or, and -not will no longer produce errors.

Function CallsFunction Calls permalink

This change will also remove special parsing for the expression() function or progid:...() functions with vendor prefixes. No browser ever actually shipped a vendor-prefixed versions of these functions, so having special parsing for them is unnecessary. Vendor-prefixed expression() functions like -foo-expression() will be parsed as normal Sass functions, and vendor-prefixed progid:...() functions like -foo-progid:bar() will be syntax errors because that’s not generally valid CSS syntax.

Phase 1Phase 1 permalink

Compatibility:
Dart Sass
since 1.98.0
LibSass
✗
Ruby Sass
✗

Currently, Dart Sass emits a deprecation warning if you define a function URL, EXPRESSION, or ELEMENT, or the same names with any combination of uppercase and lowercase letters. (Fully lowercase names were forbidden prior to this and remain forbidden.)

Function calls with these names are still parsed as normal Sass function calls, calling a user-defined function if one exists or falling back to a plain-CSS function with normal SassScript argument parsing otherwise.

Dart Sass also emits a deprecation warning for calls to vendor-prefixed expression() functions, but only if those functions will behave differently when parsed as normal Sass functions. This includes calls whose arguments aren’t syntactically-valid SassScript expressions or whose arguments would be meaningful in SassScript in a way they aren’t in plain CSS, but not calls whose arguments would be handled the same way in either case. It’s always safe to use interpolation in either case.

Dart Sass emits a deprecation warning for all vendor-prefixed progid:...() calls.

Can I Silence the Warnings?Can I Silence the Warnings? permalink

Sass provides a powerful suite of options for managing which deprecation warnings you see and when.

Terse and Verbose ModeTerse and Verbose Mode permalink

By default, Sass runs in terse mode, where it will only print each type of deprecation warning five times before it silences additional warnings. This helps ensure that users know when they need to be aware of an upcoming breaking change without creating an overwhelming amount of console noise.

If you run Sass in verbose mode instead, it will print every deprecation warning it encounters. This can be useful for tracking the remaining work to be done when fixing deprecations. You can enable verbose mode using the --verbose flag on the command line, or the verbose option in the JavaScript API.

⚠️ Heads up!

When running from the JS API, Sass doesn’t share any information across compilations, so by default it’ll print five warnings for each stylesheet that’s compiled. However, you can fix this by writing (or asking the author of your favorite framework’s Sass plugin to write) a custom Logger that only prints five errors per deprecation and can be shared across multiple compilations.

Silencing Deprecations in DependenciesSilencing Deprecations in Dependencies permalink

Sometimes, your dependencies have deprecation warnings that you can’t do anything about. You can silence deprecation warnings from dependencies while still printing them for your app using the --quiet-deps flag on the command line, or the quietDeps option in the JavaScript API.

For the purposes of this flag, a "dependency" is any stylesheet that’s not just a series of relative loads from the entrypoint stylesheet. This means anything that comes from a load path, and most stylesheets loaded through custom importers.

Silencing Specific DeprecationsSilencing Specific Deprecations permalink

If you know that one particular deprecation isn’t a problem for you, you can silence warnings for that specific deprecation using the --silence-deprecation flag on the command line, or the silenceDeprecations option in the JavaScript API.

Phase 2Phase 2 permalink

Compatibility:
Dart Sass
✗
LibSass
✗
Ruby Sass
✗

In a future release, Dart Sass will emit an error for custom functions named URL, EXPRESSION, or ELEMENT, or the same names with any combination of uppercase and lowercase letters. Calls to these function names will be parsed as special functions rather than normal SassScript.

Calls to vendor-prefixed expression() functions will be parsed as normal SassScript, and calls to vendor-prefixed progid:...() functions will produce errors.