add isVar to func to mark CSS variables usage

[AndyOGo]

Feature Use Case

// declaring a csutomproperty
element {
  --main-bg-color: brown;
}

// Using the custom property:
element {
  background-color: var(--main-bg-color);
}

https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties
https://drafts.csswg.org/css-variables/#defining-variables

Feature Proposal

I would propose to extend the Func node with isVar to mark var() calls related to using variables:
https://developer.mozilla.org/en-US/docs/Web/CSS/var
https://drafts.csswg.org/css-variables/#using-variables

[shellscape]

Interesting idea. What would be the value for the consumer in this case?

node.isVar

versus

node.name === 'var'

The latter seems more implicit to me, since var(..) is a function, and there cannot be multiple different function names to signify a variable. With the various color nodes, it was clear a boolean property made sense as there are multiple different color functions. As with url(...) we chose not to implement an isUrl because there's only one function with that name to signify a URL.

I'm not convinced that we need this property, but I'm open to being convinced.

[AndyOGo]

hmh, your reasoning is very analytical, not sure I can convince you.

I agree with you for pure CSS syntax.

I’m currently writing a stylelint plugin for CSS, LESS and SASS.
My consideration is that in Less and Sass var could also be a custom function.

And it would check that var receives the first argument with a valid CSS variable name.

I can also write a little helper within my lib, no problem

[shellscape]

I really want to discuss this, because I want to make sure your concerns are getting addressed and that you don't feel your work on this is under-appreciated. Contributors to this lib are few and rare, and I really value the help.

And it would check that var receives the first argument with a valid CSS variable name.

I see the need there. There's a shortcut for that which could be used as an alternative: node.first.isVar would tell if you if the first child of a function node (or any container node) is a variable. That could also come in handy if someone is using interpolation to sus out a variable name in a function, such like var(#{imFancy}, #{fancyDefault}). In that case, we wouldn't want to have an additional property to indicate if it was a variable function with an interpolated value child.

In your opinion, what is the likelihood (or frequency) that a user will repurpose the var function in LESS or SASS? If it's an edge-case or a maybe-case, perhaps there's another route we can take rather than making a permanent addition to the API the lib. The first thing that comes to mind is a hook (or hooks) capability that would allow consumers of the lib to customize nodes as/after they were parsed. What are your thoughts on that as an alternative?

[AndyOGo]

Thank you for your very kind answer :)
No worries I don't feel under-appreciated at all.

There's a shortcut for that which could be used as an alternative: node.first.isVar

Yes I thought so too, but then I realised that the user could potentially overwrite how variables are parsed by { variables: { prefixes: ['\\$'] }} option - though in that case he would use SASS and may never use CSS variables 🤔

In your opinion, what is the likelihood (or frequency) that a user will repurpose the var function in LESS or SASS?

I guess the likelihood approaches zero

The first thing that comes to mind is a hook (or hooks) capability that would allow consumers of the lib to customize nodes as/after they were parsed.

Totally agree, very nice idea 👍

Honestly, I think I mix the needs for a linter with the goal of a parser.
Currently I work on this, based on your lib:
AndyOGo/stylelint-declaration-strict-value#35

[AndyOGo]

closed in favour of hooks #85