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
Comments
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:
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!
For vanilla css-writer it could be a game changer, but who writes vanilla css in 2020? SASS make it so easy to write complex css simple.
css-media-vars would be a game changer for me, if it will be possible to use one var and not define many varnames and put them together to one var.
Like your Example:
If it would work something like this, it would be really awesome: OrPersonally, 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.
To be fair sass variables have been around much longer than css variables.
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.
Even if your point is good, that's just not a productive way to start out.
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.
Very impressive approach!
Do you have plans to build a full framework based on this? (Other than augmented-ui?)
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
congrats, i think this is a very good idea.
the AND and OR logic syntax a little clunky to me. i'd love something more first class from the CSSWG in accommodating this.
This looks damn interesting! Very creative.