I know the docs need a little love but I think this has potential to be a game changer for writing responsive CSS. It has named breakpoints, lets you write DRY selectors, doesn't rely on JS or any sort of build step, and if you're already used to seeing --css-variables it's easier to read/maintain too.
I've created a couple JS Bins if you want to play around with it a bit, resize the "output" pane to see it update:
If you're familiar with CSS, it may seem like it's impossible for this to work without scripts, but while working on another project I realized in the CSS Spec for custom properties that combining a few small details they've highlighted, in a specific order, it makes it possible to do all kinds of things that have never been possible before in CSS. This is the first project I've released using the idea.
I'll probably be refreshing this page for a while, so I'm happy to answer any questions or dive into the CSS Spec with you and talk about the tech if you're curious!
Personally, I believe more and more people will be writing plain CSS as its power rises. These days, if I'm quick starting something and prototyping something before the team takes it over, I stay with just plain CSS. Of course, it is faster and easier for teach new developers with Sass.
Don't take me wrong - I love SASS. Well, I wrote one of the early Less to Sass translator for Bootstrap (I think around 2009) and wrote Sass syntax plugins for the likes of Coda editor.
However, if I want to build something today that needs to stand the test of time, I know I can write in HTML + CSS and it will be still work (likely) a century from now, without me having to re-install NPM Packages and compile my Sass to CSS. Of course, I might garnish it finally with PostCSS to take advantage of the modern tooling and augment the lacking of current CSS.
P.S. Recently, I was trying to update an old project and looks like Sass deprecated node sass in favor of something new. I'm not even able to keep up with which processor is the right one to use!
I write vanilla CSS in 2020, but I suspect you're right in a "most people" sense. Still, I'm biased toward longer-lived approaches, meaning that whenever I can make it practical, I try to build with vanilla HTML, CSS, & JS with as few other technologies & libs as I practically can. Even my final HTML tends to be quite human-readable.
Again, this won't work for many projects, but the point of it is long-term maintainability. I assume that most of what is built into major, recent browsers will have the longevity of bottled wine, while technologies outside the browser will be more like fresh grapes. If I want the site itself to be more like the wine than the grapes, doing something with it years from now shouldn't require a tool that no one has used for years.
But it's not how long they've been around, it's whether they're built into standard browsers. Presumably, CSS variables can never be removed from standard browsers. They are permanently available in the web "toolchain". SASS can be replaced by something else. There will be workarounds, but it will probably be more of a problem.
The upsell on browser support is a little misleading. Sure, it’s 94% worldwide supported..but what isn’t mentioned is that the 6% is entirely IE11 and down and that the browser support numbers are inaccurate as they don’t include places like China or sorts where IE spin-offs are extremely common.
A much better way to say it is “supports almost all browsers except IE” it’s accurate (as this does support almost all browsers in the world) while details what may be a major hangup for a business user.
IE11 and down is 1.73%, not all 6%. The rest is mostly old versions of popular browsers but tiny browsers like the Chinese QQ Browser are also included at the link provided.
Anyway, I can add a note to call out that it specifically doesn't include IE for people who might not follow the resource linked at the end of the sentence you're talking about where IE11 is the first browser in the list.
Also depends on the industry sector you target. We target the third sector (charities, government, education, science, arts etc.) in the UK and regularly see ~10% IE11 use.
Thanks! No direct plans but I'll follow wherever piques my interest.
css-media-vars only happened because I recently began work on the new site/staticlandingpage for augmented-ui (v2 is my primary project right now) and was actively procrastinating because I didn't want to copy paste @media statements everywhere lol
We have two "toggle vars", `--is-hovered` and `--is-special`, which are triggered by a hover selector and a class, respectively, though they could be triggered by anything (like a media query or JS).
The "false" value for the toggle is "initial", so at the top I set:
div {
--is-hovered: initial;
--is-special: initial;
}
The first trick is that assigning a variable value as a single space token is valid according to spec (https://www.w3.org/TR/css-variables-1/#syntax), making the var(...) usage substitute a single space. So if our variable should be "true", we use whatever method to set it to a single space:
The second trick is that an invalid property value will fall back to the second argument of the `var()` function. So we first create a property that only has a valid value if the flag is true (a single space):
--hover-opacity: var(--is-hovered) 1.0;
If the div is hovered, `--is-hovered` is a single space, so the property value becomes:
--hover-opacity: 1.0; // note two spaces
If the div isn't hovered, `--is-hovered` is `initial`, so the property value becomes:
--hover-opacity: initial 1.0;
Which is invalid CSS!
We can then interpret this in our final opacity property:
If the div is hovered, the first argument is evaluated to:
--opacity: var( 1.0, var(--regular-opacity));
And since that's valid syntax, the second argument is short-circuited (ignored). However, if the div isn't hovered, then the opacity property is computed as:
YEP! Absolutely nailed it. That's what's up! I've been calling it Space Toggle. It does all kinds of stuff beyond toggle though - the whole world of conditional logic is possible. You can combine them in any way, &&, ||, !, it's all possible.
Can I ask, what’s the reason for using the keyword “initial”? As I understand it it could be any string that doesn’t accidentally create a valid value?
The OP tweet this about it [0], which links to the CSS spec [1]. It seems like a variable defined as initial triggers a different behavior than a traditional "syntax" error.
Thanks! :D I wanted really badly to be able to do it, so I read the spec very carefully top to bottom a handful of times. And suddenly one day I just realized it. Dove right in and after a bit of progress, I discovered all the logic that was possible too.
I had already been using spaces as a fallback value to do dynamic composition of standard properties ( https://twitter.com/James0x57/status/1233246818118533120 ) so it wasn't too far off to combine it with the "initial" behavior that causes the entire var dependency tree to evaluate to initial, allowing fallback behavior from any point in the tree. :)
Heads up too, Firefox and Chrome both had trouble setting a var to space from the dev tools css panel. So if you play with this further, you may have to deal with that.
Yes, that would work. Then you just assign your properties to that var as long as you never inspect --empty on the root and you're good to test. Good thinking.
Should be fixed in FF sooner or later though, I reported it in April
You're more than welcome to copy the code directly into your project (https://unpkg.com/css-media-vars@1.0.1/css-media-vars.css) or read the code, learn the technique, and implement it yourself. NPM is just one option for how to use the author's flavor of the technique.
This a profoundly creative and clever idea which I hope to never see in any actual use, ever. I really appreciate the ingenuity, but I can't help but feel its legibility and maintainability are nightmarish.
This is really cool. As I was writing some media queries today, I was yearning for a simpler solution.
Couple of nice-to-haves:
- More examples (though I'm guessing this is really new, and they will come in time).
- Guidance on best practices for variable naming (when an element has multiple responsive properties). I just ended up doing `--sm-property-name` for each variable.
Are you looking for contributors? I intend to use this approach for a project over the next few days, and I could help with the documentation.
This is awesome, build steps in CSS are absurd if you really sit there and think about what the purpose of the browser is compared to what it used to be..
No build step should be the future of web development. The more steps that are added that require yet more tools to learn and more dependencies to maintain, the less inclusive and creative the web becomes. Hopefully we will one day be able to look back on this time period as an evil necessity.. I mean writing es6 and building to es5 is way better a lot of the time from a development perspective but on the face of it, its absurd and its why tooling gives people fatigue and turns away new promising developers for better programming languages.
I would definitely provide a way to download the css without npm first. Like big worm said, its about principalities.
NPM is for convenience. Can't expect people to jump out of the build env all at once, so providing a vanilla CSS solution as a package is a good way to start the transition. IMO /shrug
Making CSS Turing complete, nice. Now we can run entire websites with functionality even if we turn JS off. Maybe we'll even see CSS only programming frameworks.
I wrote a game in CSS to demonstrate what you can do with it - https://codepen.io/onion2k/pen/qBbKYee (no mobile because I was too lazy to make it responsive). CSS is very powerful, but you need to do some weird stuff to get interactivity.
This is really smart, good job. I look forward to taking this for a spin, the point of not adding a build step is critical for some of my current work. I think the time for using CSS preprocessors is over, they add very little value now we can use variables and combined with tricks like these we can speed up our builds!
What makes this one different is that, for example, if you want to set the width, you just do it once. Other approaches (including bootstrap) you have to type "width" once for every break point where it's different.
The resulting code from this approach looks a little cleaner and nicer compared to bootstrap or normal CSS, at first glance. I'd have to test it before commenting further though.
I use something similar on my own website and it's great. However, it's very limited - I've never seen it applied to anything except for text. It's likely that for most use cases you will need to combine this with at least some traditional breakpoints.
It might work with very simple apps that have lot of excess whitespace on larger devices. You'd focus on the mobile experience first, and then on blowing it up in a visual pleasing way.
For the layout you'd use a rule based approach instead of breakpoints.
But yeah, vanilla css folks are more focused on content sites like blogs, not web-apps with dense tables, dashboards etc.
I've created a couple JS Bins if you want to play around with it a bit, resize the "output" pane to see it update:
Minimal example: https://jsbin.com/giqedowale/edit?css,output
More involved example: https://jsbin.com/yicuqujehe/1/edit?html,css,output
If you're familiar with CSS, it may seem like it's impossible for this to work without scripts, but while working on another project I realized in the CSS Spec for custom properties that combining a few small details they've highlighted, in a specific order, it makes it possible to do all kinds of things that have never been possible before in CSS. This is the first project I've released using the idea.
Anyway, it's totally free and open source too so hack away if you'd like! https://github.com/propjockey/css-media-vars
I'll probably be refreshing this page for a while, so I'm happy to answer any questions or dive into the CSS Spec with you and talk about the tech if you're curious!