shellscape/postcss-values-parser

parse negated variables

AndyOGo opened this issue · 7 comments

Feature Use Case

Support negated (and explicitly positive) variables like(non-standrad, only available in preprocessors like scss or less):

.foo { margin: -$x; }

// or

.foo { margin: +$x; }

Currently it throws:

parse: margin: -$y;

.../stylelint-declaration-strict-value/node_modules/postcss/lib/parser.js:559
    throw this.input.error('Unknown word', tokens[0][2], tokens[0][3]);
    ^
CssSyntaxError: <css input>:1:9: Unknown word
    at Input.error (.../stylelint-declaration-strict-value/node_modules/postcss/lib/input.js:127:16)
    at ValuesParser.unknownWord (.../stylelint-declaration-strict-value/node_modules/postcss/lib/parser.js:559:22)
    at ValuesParser.unknownWord (.../stylelint-declaration-strict-value/node_modules/postcss-values-parser/lib/ValuesParser.js:195:15)
    at ValuesParser.other (.../stylelint-declaration-strict-value/node_modules/postcss-values-parser/lib/ValuesParser.js:110:10)
    at ValuesParser.parse (.../stylelint-declaration-strict-value/node_modules/postcss-values-parser/lib/ValuesParser.js:135:16)
    at Object.parse (.../stylelint-declaration-strict-value/node_modules/postcss-values-parser/lib/index.js:21:12)
    at Object.<anonymous> (.../stylelint-declaration-strict-value/test-ast.js:8:31)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)

Feature Proposal

It should work similar to numeric node's isNumber test:

static test(what) {
return isNumber(what);
}

Actually in non-standard CSS languages logical not ! could also be a case 🤔

Do you have a link to the spec handy for this case?

I quickly double checked. Its not in the CSS SPEC.
The way it would be done in CSS is using calc(-1 * var(—foo)).

This is only available in non-standard CSS preprocessors like SASS and Less😇

I think this would be another chance for a custom hook?

Yeah this would definitely be a custom hook behavior, or part of a project that inherits from this. I really want to keep this module true to the spec.

I totally got your point. It's a fair decision.

Thanks. Let's figure out a good path forward for hooks.

Agreed, closeed in favor of #85