You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In cssnano compilation modes that seek to guarantee exact behavioral equivalence between the input and output CSS, transformations on custom property values should be substantially limited relative to what they are now. Custom properties aren't just used for configuring values elsewhere in the stylesheet; they may also be used to communicate information from the stylesheet to JavaScript (as in Polymer.js for example), and so the details of their JS serialization is semantically relevant. cssnano currently modifies these values like any other property, which can change the serialization and thus the semantics of the stylesheet.
There are two broad categories of issue here:
The existence of whitespace tokens is visible to JS serialization, so --foo: bar and --foo:bar are meaningfully different. cssnano will convert the former to the latter.
There's no guarantee that a custom property's value will be parsed in a context where a CSS color is meaningful, so --foo: rgb(0 0 0) and --foo: #000 are meaningfully different. cssnano will convert the former to the latter.
The second issue covers essentially all value-level cssnano optimizations, almost none of which are safe to perform on a custom property value.
Expected behaviour
There should at least be a way to tell cssnano not to make changes that could affect the semantics of the compiled CSS—which is to say, to disable essentially all value-level conversions for custom properties unless they don't affect the way those properties are serialized to JS values. Ideally, this configuration would be enabled in cssnano-preset-default, since that advertises itself as making no assumptions about how the CSS will be used.
Yeah, it is unsafe, we should provide an option to disable it, I want to keep it true by default, because most of developer use CSS inside custom properties, so it is safe in most of cases
That's fair, but in that case you should probably change the description of cssnano-prefix-default to avoid saying it makes no assumptions. (Probably just enumerating the assumptions it does make is sufficient.)
Describe the bug
In cssnano compilation modes that seek to guarantee exact behavioral equivalence between the input and output CSS, transformations on custom property values should be substantially limited relative to what they are now. Custom properties aren't just used for configuring values elsewhere in the stylesheet; they may also be used to communicate information from the stylesheet to JavaScript (as in Polymer.js for example), and so the details of their JS serialization is semantically relevant. cssnano currently modifies these values like any other property, which can change the serialization and thus the semantics of the stylesheet.
There are two broad categories of issue here:
The existence of whitespace tokens is visible to JS serialization, so
--foo: bar
and--foo:bar
are meaningfully different. cssnano will convert the former to the latter.There's no guarantee that a custom property's value will be parsed in a context where a CSS color is meaningful, so
--foo: rgb(0 0 0)
and--foo: #000
are meaningfully different. cssnano will convert the former to the latter.The second issue covers essentially all value-level cssnano optimizations, almost none of which are safe to perform on a custom property value.
Expected behaviour
There should at least be a way to tell cssnano not to make changes that could affect the semantics of the compiled CSS—which is to say, to disable essentially all value-level conversions for custom properties unless they don't affect the way those properties are serialized to JS values. Ideally, this configuration would be enabled in
cssnano-preset-default
, since that advertises itself as making no assumptions about how the CSS will be used.Steps to reproduce
Copy/paste this into https://cssnano.co/playground/:
Version
5.1.14
Preset
default
Environment
Package details
Additional context
No response
The text was updated successfully, but these errors were encountered: