Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hashing on css variables #1241

Open
fa93hws opened this issue Dec 11, 2020 · 7 comments
Open

Hashing on css variables #1241

fa93hws opened this issue Dec 11, 2020 · 7 comments

Comments

@fa93hws
Copy link

fa93hws commented Dec 11, 2020

Feature Proposal

css variable: https://developer.mozilla.org/en-US/docs/Web/CSS/var

There are cases where we want to use the css variable instead of the @value for the responsive design.
Say assume I have

<div class="parent">
  <div class="child">
  </div>
</div>

I would like to have some variable to synchronize some property between child and parent and this variable is designed to be responsive so @value can not be used here.
Instead of overwrite each rule in @media, I would like to do something like: https://jsfiddle.net/g86efhas/2/

The problem is the css variable may leads to some name clash.
So is that possible to add the hash to css variable as well

Feature Use Case

Use css-variables and forget about name clashing.
css(--var) -> css(--src-pages-foo-bar-var)

@fa93hws fa93hws changed the title Hasing on css variables Hashing on css variables Dec 11, 2020
@alexander-akait
Copy link
Member

Sorry, it is unsafe, css variables is hoisted, can be used in JS or in other CSS files, even inside style tags in HTML files, so renaming them is unsafe operation, also I think it is out of scope css-loader and CSS Modules

@upsuper
Copy link

upsuper commented Dec 13, 2020

Sorry, it is unsafe, css variables is hoisted, can be used in JS or in other CSS files, even inside style tags in HTML files, so renaming them is unsafe operation,

I think this very reason applies to class names?

also I think it is out of scope css-loader and CSS Modules

It's also about modularization of individual CSS files to avoid sharing a global namespace, isn't it?

@alexander-akait
Copy link
Member

I think this very reason applies to class names?

class names are not hoisted

It's also about modularization of individual CSS files to avoid sharing a global namespace, isn't it?

As I said before it is unsafe (but we can't rename them in JS or HTML) and maybe better to solve this on minimizing step

But we can implement this

@upsuper
Copy link

upsuper commented Dec 14, 2020

class names are not hoisted

What do you mean by "hoisted"?

but we can't rename them in JS or HTML

If it can be imported into js just like class names, this shouldn't be a problem I suppose?

@alexander-akait
Copy link
Member

What do you mean by "hoisted"?

getComputedStyle(document.documentElement)
    .getPropertyValue('--my-variable-name');

https://davidwalsh.name/css-variables-javascript

If it can be imported into js just like class names, this shouldn't be a problem I suppose?

You still can use variales in HTML and JS or in other CSS files (which can be not part of webpack bundling)

@upsuper
Copy link

upsuper commented Dec 14, 2020

You still can use variales in HTML and JS or in other CSS files (which can be not part of webpack bundling)

How is that different from class names? You can still use class names outside webpack building as well I think? What makes CSS variables more unsafe?

getComputedStyle(document.documentElement) .getPropertyValue('--my-variable-name');

What is the problem here? There are lots of CSSOM functions which can take class names as well. I still don't quite see the difference.

@alexander-akait
Copy link
Member

paint worklets will be broken too

PR welcome, because it is unsafe (more unsafe than class names), I mark it as lower priority

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants