Add support for CSS custom properties

[Chalarangelo]

Many of the variables used in the framework can be changed from SCSS variables to CSS variables.

However this feature is not well-supported yet, thus it will be some time until the framework changes to CSS variables. This is a planned change and it will take place sometime later, when support for the feature is over 85% (currently at 66% as of October 2016).

[chriscauley]

Currently there are functions that won't work with css variables. Specifically make-button-alt-color fails when var(--blue) is passed in as a color. It errors out on the SASS function rgba($button-alt-back-color, $button-alt-back-opacity). To solve this for now I changed the function to make it optional in this commit where I only mix color and opacity if opacity is not equal to 1:

https://github.com/chriscauley/mini.css/commit/d5e46b4ad6740bca55187e5f9534e1f9f1d0c2c4

Let me know if you want this as a pull request. I'm more than happy to update other parts of the code to work this way. As for the browser support, I'm currently using http://www.myth.io/ to preprocess my css and support older browsers.

[Chalarangelo]

Thank you for the feedback and suggestions. If you check the New feature backlog, you'll see that this feature's implementation is on hold for now, due to lack of browser support.

The final implementation I had in mind should allow some base variables to be adjusted in CSS, while some things remain written in Sass. At this time, it is unclear when and how this feature will be implemented.

Myth.io seems like a very good preprocessor, however I am not ready to make the switch from Sass yet. If you are willing to undertake the project of creating a myth.io fork and maintaining, I would be more than happy to include the fork in the package, however the Sass version will be the main version for the time being.

(Meanwhile a LESS fork should be built as well, but I haven't had the time to build one.)

[Chalarangelo]

Update

CSS variable support is at 70.9%, which is nowhere near 85%, but still it's reasonably interesting. Some internal tests and experiments will be carried out in the following weeks to determine what parts of the framework would most benefit from the use of CSS variables, so that future releases can start utilizing them.

This said, there might be an experimental, more modern, flavor coming in the next releases that will use both this and other not-so-well-supported features that modern browsers could utilize.

[GuskiS]

Would it be possible to have a mixin in places where SASS variables are being used? For example, I have something like this in my project:

@mixin variable($property, $variable, $fallback, $default: null)
  #{$property}: #{$default} $fallback
  #{$property}: #{$default} var(--#{$variable})

// Usage
@include variable('border', 'color-main-shade-1', $color-main-shade-1, '1px solid')

This approach creates 2 border: 1px solid. One with var and other fallback to SASS variable. Mixin could be improved with some kind if which would check developer wants to use CSS variables (and fallback) or just plain SASS variable. This works pretty well in most cases for me. What do you think?

[Chalarangelo]

@GuskiS that can certainly be implemented, although this will take a lot of time in order to update the whole codebase. I'll look into it! 😉

[GuskiS]

Looking forward to it. I haven't yet used mini.css, but will in future. I just removed all bootstrap JS related components, next is to switch from bootstrap to mini.css :)

[Chalarangelo]

CSS variable support is at least a couple of months away, if not more, due to the extensive work it requires on my part refactoring the codebase. Right now, I am planning to add a couple of minor features to mini.css, such as a toggle (switch) and a modal dialog to finalize the component list. Afterwards, I am planning to patch a lot of things to make everything even smoother and lighter and update pretty much everything to allow for Sass variable maps to make customization a lot easier. Last but not least, CSS variable support will be added right after the maps and stability patches, as the final update before the first real LTS release. This will mark the release of v3.0.0, which (in Google-like fashion) will be name Gluon and will be the first Long Term Support release, as soon as any bugs are figured out (hopefully right away).

In the meantime I am working hard on implementing a React-based library for mini.css that will be actively maintained, allowing all newcomers to adopt it more easily in their projects. If I manage to figure out how to port it to Vue, without taking forever to do so, I will add support for it as well. This is the top priority right now for me.

However, if anyone is willing to actually help me out porting to CSS variables, I would be really grateful, as I have barely any time to work on all of these things. Fork, work on it, pull request, comment here, highlight a list of things that can be CSS variables, pretty much anything. I could use the help right about now. Know of anyone who can be part of this and help out? Get me in touch with them. I'd love for the community to jump right in and help out in the ongoing development of the framework and the ecosystem I'm trying to build around it!

[GuskiS]

Maybe you could create a mixin for it and work could happen one component at a time? That would allow you (or any other person) to add it if they are making some changes to component. But probably to do that there should be some ground rules, like you mentioned, what actually should be turned into this dual system. That would actually allow to specify multiple/specific if checks, for example, if developer doesn't want to use CSS variables on some pixel related (or component based, yet to be determined) but want to have it on colors (or other components, if the second approach).

If this could be done in by you or any other person(and discussed), I might give a shot on to try to do something like that. But don't count on me 😆

[Chalarangelo]

Ok, rules are as follows (this is a first draft, feel free to help out):

• Add a _globals.scss file that will encapsulate just the required flags for now for CSS variables (maybe more things in the future? Otherwise it's a bit of a waste).
• Add a $_global_enable-css-variables flag (true/false) in said file, which will enable css variable polyfills (so that there is a fallback if need be).
• Add a $_global_enable-pure-css-variables to use only css variables instead of hardcoded values. This will help make things easier down the road in a couple of years that css variables will be pretty much standard in every browser, allowing maintainers to just kill support for older browsers at their own discretion.
• Then, one module at a time, the implementation should be added to pretty much all variables that make sense (padding, margin, border, border-radius, font-size, color, background etc.).
• As a starting point, I would say colors are the most important thing to allow variables for, as they will make customization a whole lot faster and easier for developers using variables (they will literally just import the css file from the flavor they like and alter the color variables, which is as fast as possible to get started with).
• Modules that should not be touched are msot likely grid and utility, as they are really really complicated in terms of variables and breaking them is very easy if not done properly. Leave those for last and let me code them, as they will not really affect that much anyways.
• All pull request should be against a new branch (I will open a next branch tomorrow morning, starting to patch things for everything that will be built and I will also open a cssvar branch to work on this feature in specific.
• Avoid the two modules that are going to be changed for the next month (i.e. contextual and input_control). Both will see a few updates and changes and they will most likely be unstable to work on for a bit.
• Please report all findings about bugs and irregularities and keep a DEVLOG, like I do (link). Name it something like username_DEVLOG.md and put it in the 📁 v2 folder, so that I can more easily find what is done by whom in the future.

Okay, I think that's all. It's just a draft, but I hope we have a template going forward. I will be looking into certain things before the next patch, maybe I will add the _globals.scss file to get this whole thing started and I will try to figure out what modules are the best fit to work on first.

Update: Global support for css variables is now at 72.03% (source). Meanwhile, the support for the feature in EU/US 80% and around 69% in the Asian markets, meaning that switching to css variables is kind of high priority for the framework right now.

[Chalarangelo]

Update

v2.2.1 was rebranded as v2.3.0, as there is a lot of changes to be added. I will try to squeeze in the variable mapping in this update (no promises yet), so that using CSS variables can become a lot simpler later down the line. Polyfilling for older browsers will be a pain, though, so I might actually start noting down on paper what should be kept as Sass variables. All current work is now on the next branch, so be sure to check out the progress of the update.

[Chalarangelo]

A great primer on the subject of CSS custom properties and proper scoping can be found here.

[Chalarangelo]

Update

After the release of v2.3.0, the only thing missing from mini.css is Sass maps that will help people change everything more easily. CSS custom properties will be added right after maps are implemented, although there is a lot of work to be done to add support for those.

[Chalarangelo]

Update

With the official release of the React/Preact libraries for mini.css, I will now take a short break (about two weeks) to work on some other projects, especially ones I need to take care of for college. I will get back to the development of the framework (some bug fixes are actually in the works already) from time to time and eventually I will take care of the Sass maps and variables situation, but this might be sometime later this summer (actually I'm targeting late August to bundle these changes along with a lot of support changes for older browsers, provided some of the proxy browsers and IE will have been dealt with one way or another). Anyone interested in undertaking any bug fixes, the Sass maps or variables (even partially), please reply to this thread and work on your own fork. I'll be seeing you around!

P.S.: I will also be working on some tutorials for the framework, the first of which is already out on Hackernoon (link).

[Chalarangelo]

Update

It's been a little while. The bad news is that I am nowhere near ready to start working on the CSS variables implementation just yet. The good news, though, is that, due to CSS custom property support going up every month, I will most likely not need to implement Sass maps and I can focus on CSS variable support right away.

The release of v3 is a good few months away, so don't expect any major changes until at least late October or something like that. I will be updating the framework and maintaining it, as usual, so expect patches and flavor updates every once in a while. v3 will focus on giving the framework more of a personality, making sure everything is polished and shiny and that the latest features that are well-supported are used in the framework to provide a great foundation for the future. UX is a major concern (both developer-wise and end-user-wise), so there is plenty of work to be done in that direction before the next major release. I will try to get an alpha branch up and running soon enough, so that any new features and updates can be tested by developers in order to get feedback.

Stay tuned and have a nice summer! 🍸

[Chalarangelo]

Update

Part of the Gluon release will be support for CSS variables. You can see the roadmap in #97.

The specifics of CSS variable support are not 100% decided yet, but here's what I've come up with:

1. CSS variables will be used in conjunction with Sass variables.
2. CSS variables should serve ease-of-use purposes, so developers can grab a flavor file, tweak a few things in pure CSS and make a customized flavor for themselves.

Based on (2), what I think is the optimal approach for now is the following:

• Use CSS variables for color palettes. This will allow similar flavors to branch out from the same flavor file, effectively letting developers customize the color theme of their websites, while keeping the website functionality intact.
• Avoid using CSS variables for properties defined and used only one. Things such as the font-family property in the root element, which is the native font stack defined only once are bad candidates and can be easily tweaked without the need for CSS variables.
• Use CSS variables for universal properties. The side padding of many elements is a prime candidate for this, as well as some margins. This will definitely help developers tweak a flavor as a whole to get the desired effect.
• Avoid using CSS variables for complicated properties (such as border shorthands) or things that could break the framework in spectacular ways.
• Use CSS variables to improve fluidity and responsive design if at all possible. The grid module and fluid typography could be prime candidates for this application, however it might be impossible to implement any of these, so no promises just yet.

For anyone not up-to-date, development on Gluon has just begun, so expect frequent updates. v3.0.0-alpha.1 will be arriving in November at the very latest, so expect to see some CSS variable support in it.

Update

I will try to list any changes I make below:

• Main palette colors (foreground, secondary foreground, border color, background etc.) are now part of the CSS variables implementation.
• Heading elements (h1-h6) will be using a CSS variable to specify a universal ratio. This will increase minified code size by about 30-50 bytes, but will allow for very easy tuning by developers, who want to change the heading scaling.
• Universal margin and padding properties have been specified which will be used to avoid fine-tweaking elements, so that they can be easily used to specify most margins and paddings for elements. Pretty convenient if you want to make changes on the fly. A similar variable has been created for border radius.
• Some element-specific colors have been added for blockquotes, pre elements and links. These should help simplifiy the process of tweaking said elements.
• All CSS variable names are customizable on a per-flavor basis, utilizing SCSS variables for ease-of-use and to avoid conflicts with other CSS code.
• The grid cannot have customizable breakpoints, as var() is not supported inside @media. This was a cool idea, but it cannot be done due to specs. No big deal, though.
• Tweaking the font-size of html should never be done via the CSS file and must always be followed by recompiling the SCSS file, as the values of such SCSS variables as $__1px and similar are based on that. It's a bit of a hassle, but it's for the best.
• The grid module was to originally feature its own variables for padding, but they were ultimately tied to the universal variable for simplicity. Tweaking them via changing the code in the SCSS file of the module is extremely easy, too.

[Chalarangelo]

I am closing this issue, as it does not offer anything particualry useful right now. If you want to talk about how CSS variables play with the upcoming Gluon release's code, please move the discussion to #97.