Feature: Support CSS Custom Properties (Variables) #1837
Comments
|
It’s already used for variable width columns. You could also set it with your own Sass variables. |
|
Not really. If I want |
|
+1 Would also like to be able to use CSS variables when customizing Bulma. |
|
+1 CSS variables! please! |
|
This issue was closed, can you @jgthms open it again and Maybe add the label |
|
CSS variables are reactive and would be much easier to use, especially with frameworks that currently have you load Sass variables first so they can be reused anywhere in the app (like Nuxt) |
|
+1 CSS variables please! it's perfect!!! |
|
Any updates on this? |
|
I’m trying to find a way to make both Sass variables and CSS variables coexist. It seems that some developers only want the former, some the latter, and some a mix of both. There’s a few ways to handle this. For example the Sass variables could be transformed into CSS ones. Or Sass ones could reference CSS ones. Anyway, I’m still looking to find a way that doesn’t break existing setups and that is modular enough for developers to choose their own way of coding. |
|
@jgthms I love the idea of Sass being transformed into CSS vars so you can choose the level of abstraction you want to override 1) Sass, more powerful with its functions, nice if you want to override a lot of things, add new breakpoints, etc 2) CSS vars if you want to avoid a build step and/or you don't need to override too much. In my case, I'm working on a visual code editor that uses Bulma as the default UI Kit, and it would be really powerful if my tool could only override SASS when necessary, but update CSS vars in most cases. The 3-5 second Sass compilation time (done client-side) really slows things down. Just my 2 cents. |
|
@jgthms Wouldn't this cause a problem with methods such as |
|
@jgthms any updates? |
|
There's a branch here, "in progress" in the Road to v1 project, wait & see 😄 |
|
Yes that branch is like a playground for me to try out different ways to support CSS variables. It's mostly the |
|
I gave it a try to automate the process: bulma-css-vars | Demo For each sass function call it creates a new variable, e. g.: $green: var(--green)
color: darken(findDarkColor($green), 5%)
// becomes
color: var(--green--dark-color--500--darken)I also added some logic in js to automatically calculate all of these derived variables. If you include a js part of updater.updateVarsInDocument('black', '#553292');The tricky part for me was to only render the required variables as css variables, not all of them by default to avoid bloating up the styles. IMHO a pure sass/css solution would not be possible, as so many styles are derived from others (like shades of buttons / inverted colors for button labels) and there are no CSS functions available to do this in the browser without JS.
related: #1775 |
|
I got tired of waiting so I created my own framework. It is used for creating the new GUI of the open source (IoT) operating system named ESP Easy. I will release it when I have the entire SPA (single page application) done. |
|
Here's a preview of my framework including a theme creator / importer / tweaker.
|
|
Screenshots of two different settings.
|
|
The only thing I'm missing now is to have a CSS styling of icons (see my suggestion here: https://discourse.wicg.io/t/icon-semantic-html-element-icon/3915). That way I could also make the icons follow the "button radius" variable and become sharper/rounder accordingly. |
|
https://github.com/letscontrolit/GUIEasy if you want to be inspired :) |
|
Is there any update on this? |
|
One way of doing this would be to prepare a separate version of Bulma that supports CSS variables on the server side. This way, you could have a post build script, that runs after the pre-packaged version of Bulma is uploaded to the site. This way would ensure that the current version of Bulma is not affected at all, and the complexity of SASS vs. CSS variables would be gone, since thay have separate code paths. |
|
Another way would be to have a web app where you could customize Bulma, and download a pre-built version that matches your desired customizations. This would not work for people that want to dynamically change styles, but it would help people like me, that just want to get rid of the build step, and still customize a few variables. |
I'm not sure I follow. Your suggestion is to have alongside the normal |
@EmilStenstrom It's a valid idea, but it would most likely involve having to write some custom build step to transform Sass variables to CSS variables. Also, most likely all variables inside the source files shouldn't be exposed. Another, probably more complicated issue, is that Sass's color transformations can't be applied to CSS variables as of right now. And finally, CSS variables aren't supported in a few browsers, meaning that proper fallbacks must be implemented. |
|
@jgthms Yes, that was the idea. Not saying that any of them are any good, just that if there's a simpler way of doing this, ideally that someone in this huge thread could help with, everyone would be happy. |
You are right, this is probably a better way.
Agreed, there's an API today, makes sense to expose only the same one via variables.
Yes, this would be the tricky part. Maybe we could rewrite the needed color functions using calc or mix-blend-mode?
Fallbacks are only necessary if you need to support IE11, and there are many cases where that's an OK thing to just skip. Since the current version would still be there, this could just be added as a note when downloading. |
|
@EmilStenstrom @scriptcoded about browser support looking #2882 I don't think there is the idea to support IE 11 in the next breaking version |
Yeah okay with that in mind we've only got the technical implementation to cover 😅 An alternative method to trying to come up with live CSS variable transformations (which I think will be incredibly hard) would be to pre-calculate the values beforehand, and generate a set of CSS variables for different "themes". This would more or less mean using CSS variables for switching between palettes rather that supplying exact color values. It would, however, mean a lot less generated CSS compared to the "usual" theming solution which involves wrapping all classes with some form of theming function (https://blog.prototypr.io/how-i-theme-my-react-app-with-sass-414e8f905541). Of course, this would only be applicable if CSS variable support is supposed to allow theming, and not live specific color selection. |
|
It's possible to overwrite most of the mixins used so they can work with css variables That combined with a build script that will extract all the declared variables with sass-extract and add them to the :root selector and replace all the variable used in css to a function v(varname) It would then be fairly easy to have two build scripts one for a themable version with css variables and one without I'll try to make a working demo |
|
@Tofandel that's exactly what I did in https://github.com/wtho/bulma-css-vars |
|
@wtho That's not really how I envisioned it I've almost finished so stay tuned for a PR |
|
🎊 As you can see it's fully backward compatible with the current version, having the same variables (except for the $sizes list but no way around it) and the same generated css (I just made 2-3 optimizations) The compilation to extend bulma importing it via sass will still works, but need to follow the same logic to be themeable (using I now need to make a script to generate the themes where you input your sass file with variables and it will give you the correct :root + theme css I may also add a shortening function to shorten the variables names if needed The diff in size is |
|
I am a bootstrap user, frustrated with situation of allowing my users to theme their online store (multi-tenant SaaS). Basically, user configures the vars based theme on server side. I have an endpoint that dynamically emits those vars ( At runtime, in the browser I want my store to be theme-able by the user as a result. I am currently repeating work by forcing overrides on case by case basis... I'd expect this to be done by a framework though... a run-time framework that uses CSS custom vars. I'd be an instant convert to Bulma, if this feature was available. |
|
Same situation for me here, SCSS varaibles were enough as long as it was at build-time, but when you need customization at runtime it's trickier. Use cases ?
All SaaS that envolves giving the hand to your users either by choosing specific properties or by choosing a theme. The theme issue can be fixed by creating one .scss file per theme and build all themes on every deploys but this only works when your themes are predictable and not community-based. When you want to create a community-based theme editor you need to leverage a CI to regenerate seperate theme files on the go when your user data changes or you need to leverage custom css properties which is way more flexible. Basically today I have to do stuff like: const customCss = `
body,
strong,
.box,
.label {
color: ${textColor};
}
.has-text-black.is-custom {
color: ${textColor} !important;
}
.hero.is-light.is-custom {
background-color: ${bgColor};
color: ${textColor};
}
`;
const style = doncument.createElement('style');
style.textContent = customCss;
document.querySelector('head').appendChild(style); |
|
Anyone know if there are still being worked on this issue? And if so, are there any release plan for it? |
This is not working for the last version on bulma i have this error on this specific variable. |
|
@pedropcruz any luck with that? |
|
@pedropcruz @victorheid I highly suggest you open an issue at https://github.com/wtho/bulma-css-vars/issues instead of notifying over 20 participants and more possible observers of this issue. |
|
Checkout @bulvar monorepo. |
|
Any progress on this? |
and others
Overview of the problem
This is about the Bulma CSS framework
I'm using Bulma version 7.0.0
I am sure this issue is not a duplicate?
Request:
I've noticed it's on Bulma road v1 the support to CSS Variables. Do you have in mind a deadline for it?
Thank you.
The text was updated successfully, but these errors were encountered: