bulma
bulma copied to clipboard
jgthms
Feature: Support CSS Custom Properties (Variables)
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.
It’s already used for variable width columns.
You could also set it with your own Sass variables.
Not really. If I want $primary to be var(--primary), being --primary #008080 it doesn't work.
>> Error: argument `$color` of `darken($color, $amount)` must be a color
>> on line 104 of node_modules/bulma/sass/base/helpers.sass, in function `darken`
>> from line 104 of node_modules/bulma/sass/base/helpers.sass
>> from line 5 of node_modules/bulma/sass/base/_all.sass
>> from line 5 of frontend/simple/sass/bulma_overrides/base/_index.scss
>> from line 3 of frontend/simple/sass/bulma_overrides/index.scss
>> from line 9 of frontend/simple/sass/main.sass
>> >> color: darken($color, 10%) !important; } }
Totally agree with OP.
https://caniuse.com/#search=custom%20properties
http://lea.verou.me/2016/09/autoprefixing-with-css-variables/
https://www.youtube.com/watch?v=2an6-WVPuJU
+1 Would also like to be able to use CSS variables when customizing Bulma.
This issue was closed, can you @jgthms open it again and Maybe add the label needs work and feature ?
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
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 lighten or rgba? In my head this creates an issue with assigning SCSS variables CSS variable values, since the SCSS calculations are done before the CSS variables are even defined. Of course this wouldn't be a problem if the last step after assigning all SCSS variables would be to generate the CSS variables.
Yes that branch is like a playground for me to try out different ways to support CSS variables. It's mostly the darken() and lighten() Sass functions that are hard to replicate. I found a way but it's not the simplest.
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 bulma-css-vars in your website as well, you can update a variable and all its derived variables using a function:
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. bulma-css-vars also uses the original bulma source and only overrides functions in utilities/functions.sass.
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.
bulma-css-vars is a proof of concept, feel free take any inspiration from my work to bring this issue forward. It also currently only works with colors (I think)
Cheers!
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.
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.
From my experience with creating a CSS variable based framework is that by design you're forced to create it in such a way that it is scaling correctly. Pre-processing (Sass etc.) takes this away from the designer and the result is that many components break when applied on borderline screens and elements.
@jgthms I'm here if you want to discuss 😄
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.
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.
I'm not sure I follow. Your suggestion is to have alongside the normal Sass -> CSS version, another version that is Sass -> CSS -> CSS, which somehow transforms the bulma.css into a bulma-css-variables.css file?
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.
@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.
@scriptcoded wrote: @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.
You are right, this is probably a better way.
Also, most likely all variables inside the source files shouldn't be exposed.
Agreed, there's an API today, makes sense to expose only the same one via variables.
Another, probably more complicated issue, is that Sass's color transformations can't be applied to CSS variables as of right now.
Yes, this would be the tricky part. Maybe we could rewrite the needed color functions using calc or mix-blend-mode?
And finally, CSS variables aren't supported in a few browsers, meaning that proper fallbacks must be implemented.
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 https://github.com/jgthms/bulma/pull/2882 I don't think there is the idea to support IE 11 in the next breaking version
@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 :sweat_smile:
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 https://codyhouse.co/blog/post/how-to-combine-sass-color-functions-and-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
@wtho That's not really how I envisioned it I made a breaktrough with node-sass compilation and custom functions I can retrieve all the variables used in the custom function and first build a non themeable, then run it a second time with all the themeable variables output in the function rather than the value
I've almost finished so stay tuned for a PR
:confetti_ball:
https://github.com/Tofandel/bulma/blob/master/css/bulma.themeable.css
If people want to beta test to make sure there is no computed color difference as it is now handled with hsla( calc(var(--v-h) + h, calc(var(--v-s) + s, calc(var(--v-l) + l, calc(var(--v-a) + a) )
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 v function and using the same build script)
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 bulma.min.css (190Kb => 25Kb gzip) bulma.themeable.min.css (250kb => 32kb gzip)
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 (:root), mostly colors.
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. @jgthms @Tofandel
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 ?
- Page editors
- Template editors
- Multi-tenant Stores
- Dynamic Theme systems ...
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?
It's possible to build a CSS Variables Bulma using this developed by @wtho. It took me a bit to catch it up, but works like a charm!
It's possible to build a CSS Variables Bulma using this developed by @wtho. It took me a bit to catch it up, but works like a charm!
This is not working for the last version on bulma 0.9.2.
i have this error on this specific variable.
$ node ./node_modules/.bin/bulma-css-vars --init
(node:17147) UnhandledPromiseRejectionWarning: Error: Undefined variable.
╷
91 │ @return $background
│ ^^^^^^^^^^^
╵
node_modules/bulma/sass/utilities/functions.sass 91:11 findLightColor()
node_modules/bulma/sass/utilities/derived-variables.sass 26:17 @import
node_modules/bulma-css-vars/bulma-cv-utilities.sass 4:9 @import
node_modules/bulma-css-vars/bulma-cv-lib.sass 3:9 @import
src/main.scss 3:9 root stylesheet
at Object._newRenderError (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:13498:19)
at Object._wrapException (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:13341:16)
at StaticClosure._renderSync (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:13316:18)
at Object.Primitives_applyFunction (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:1089:30)
at Object.Function_apply (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:6007:16)
at _callDartFunctionFast (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:7676:16)
at Object.renderSync (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/sass/sass.dart.js:7654:18)
at Object.renderSass (/home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/bulma-css-vars/dist/render-sass.js:7:27)
at /home/pedropcruz/WORK_PROJECTS/FIDGROVE/PLATFORM/platform-frontend/node_modules/bulma-css-vars/dist/cli.js:90:43
at Generator.next (<anonymous>)
(node:17147) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:17147) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
@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.
