[Feat] CSS variable scoping

[jjenzz]

currently if i do the following, intellisense will still list the --color var as an option in .two and will not error if used:

.one {
  --color: red;
}

.two {
  color: var(--color);
}

this got me thinking. if a "prefix" was defined in the extension settings to denote "private variable" would the extension be able to filter things? for example:

"cssvar.scopePrefix: "_", // would be underscore by default

then:

.one {
  --_color: red;
}

/* typing `--` here will not list vars containing underscore prefix unless they are declared within `.two` */
.two {
  color: var(--_color);
}

[phoenisx]

This is a good suggestion, and I wanted to implement it as well, but it's tricky since CSS class scoping is not decided within CSS, but it's scoping is decided by HTML files.

For e.g.:

<!-- Head -->
<style>
  .parent {
    --color: #a45;
  }
  .child {
    color: var(--color);
  }
</style>
<!-- Body -->
<div class="parent"> <!-- could've been ".one" -->
  <p class="child">Hello World</p> <!-- could've been ".two" -->
</div>

An ideal linter should parse and find CSS scoping from HTML files, which taken today's various JS frameworks and whatnot is tricky unless we have a plugin/loader that binds to a linter or a bundler respectively.

I am not sure that variables defined and used in separate classes should be considered a lint warn/error. Even if they have different scopes, initially, it can change anytime and the errors might become confusing.

What do you think?

[jjenzz]

i think that coming up with some coding standards can help with all of this without the need to parse HTML. intellisense can avoid making suggestions that go against those rules, along with a linter that can error when those rules aren't met. for example:

--_background-color could mean scoped to the current class only so intellisense would not suggest it in any other scope (and could fail usages outside of that):

.one { --_background-color: red; }
.two { background-color: var(--_background-color); } /* error */

--button_background-color could mean "background-color" for .button scope so intellisense would not suggest it unless class is prefixed with .button-- or .button__ (using BEM as example but class naming convention can be a configuration):

.button { 
  /* private */
  --_color: red;
  /* exposing private var to `.button__` / `.button--` blocks */
  --button_color: var(--_color); 
  /* using private var */
  border: 1px solid var(--_color); 
}

/* intellisense suggests `--button_color` and passes when used because it is in `.button__` scope */
.button__text { color: var(--button_color); } 

/* intellisense wouldn't suggest this and errors when used because it isn't in `.button__` / `.button--` scope */
.one { color: var(--button_color); }

people can obviously bypass these rules and still use the variables in an unintended way, but they would be breaking the coding standards and working in a codebase full of errors.

this can be taken further by integrating the coding standards into stylelint so the build could fail. that way, the following HTML wouldn't matter, the build would have failed before it could render:

<button class="button">
  <span class="one">Hello</span>
</button>

i do wonder if this is starting to push the boundaries of the original goal of this extension tho 😅

[phoenisx]

😅

I agree and also feel this can/should be a PostCSS plugin rather than part of this extension, and if already present can work with this extension without any changes.

What I feel is adding support for stylelint's PostCSS plugin would be a better option instead of redoing things.

I have never tried stylelint with this extension, so not sure if it will work or not.

[phoenisx]

~~On second thought, I think using these linters directly as a plugin to this extension would cause issues because they all work in strict mode. What I mean is if the CSS has errors or wrong structure it will completely fail the parsing of the source file. Which in our case will completely stop showing IntelliSense for CSS variables 😅 This extension parses the Source files irrespective of them having errors, which is just the opposite of what stylelint is doing.~~

Wait!!! 😅 Let me try this first. I will update if supporting Stylelint is possible. If it is, then a lot of these things can be set up by Users instead of adding them to this extension.

[jjenzz]

If it is, then a lot of these things can be set up by Users instead of adding them to this extension.

that would be super useful.

if i was to build something like this into a stylelint / postcss plugin tho, would we get the intellisense features i mentioned? e.g. --_color wouldn't be suggested in .two.

[phoenisx]

I looked into these extensions:

• Stylelint (Official)
  • Only allows linting, no support for IntelliSense. I feel that's on purpose.
• PostCSS (Unofficial), the only one actively maintained I guess 🤔
  • No extensibility. Provides CSS autocompletes, but no linting or add-on IntelliSense for CSS variables, which again was created as a separate extension.

Supporting Stylelint config and its config with this extension might provide the best of both worlds I guess 😄. Not sure if anybody is already doing something like that.

What do you think?? Should I create a new extension from scratch that provides the following features in the same extension 😜:

• PostCSS language support, like highlighting and stuff for .pcss/.postcss files (already exists though, as mentioned above)
• Intellisense for PostCSS including CSS variables built-in (I don't think anybody is doing this yet)
• Lint support (Stylelint).

[jjenzz]

Only allows linting, no support for IntelliSense. I feel that's on purpose.

i was aware of this one which is what prompted my previous question. tis a shame!

Supporting Stylelint config and its config with this extension might provide the best of both worlds I guess

that would be the ideal scenario! if this extension could parse a stylelint config and follow the same "rules", in that, anything that errors would not be suggested and anything that warns would highlight that in the suggestion somehow... i would be in heaven.

What do you think?? Should I create a new extension from scratch that provides the following features in the same extension

i'm going to DM you on twitter if that's okay. are your DMs open?

[phoenisx]

I'm going to DM you on twitter if that's okay. Are your DMs open?

Sure!! I do feel the extension we are thinking of might need a bit of experimentation, coz I am not sure how much of it can be supported using VSCode's API, but I feel it's doable 👍🏽

[jjenzz]

Sure!!

amazing, i sent one now... it might have fallen into your "message requests" inbox.