Also please fix the title. Someone used a computer that automatically turns -- into – (en-dash), and the space between the colon and semi-colon got dropped.
This is a very clever hack, I had no idea that initial meant that the fallback would be used.
I am all for clever hacks but more needs to be done when it comes to explaining to experienced developers and new people exactly how to use CSS variables. It has been a difficult journey and we still have people doing their own weird things with LESS/SASS precompilers and not writing maintainable CSS.
Came here to post same.
https://every-layout.dev is a game-changer. The free content is a goldmine, and having spent $100 for the complete set of reated materials (book, component generator, etc) I can say I've gotten easily 10x that value out of it, maybe more. Hands-down the best CSS-related resource I've encountered since starting my career in web dev in 1998 (ie, before CSS was created).
> explaining to experienced developers and new people exactly how to use CSS variables
Don't? They don't work in IE. By the time you've written a fallback you've complicated things just as much as Less/Sass would but without the benefits of those.
Please actively seek to not support IE. It’s long-obsolete and needs to die. By supporting it, you help to keep it alive, which makes trouble for all of us. (“Why doesn’t your site work on IE? Their site does!”—and all of a sudden there’s pressure for you to support IE.)
If you don’t have any evidence that you need to support it, I strongly recommend deliberately removing support for it, whether that means just not caring if it works or not or actively breaking it (though please implement that as an IE blacklist, not a certain-browsers whitelist). If you do have evidence that you need to support it, push to remove it, even if you can’t remove it just yet. If you can stop supporting IE, it will make your life easier and it will make my life easier.
I hate IE as much as the next guy, but PLEASE DO NOT DO THIS! s/IE/Firefox/g to see why.
Polyfills are available for most of the usual things and they're absolutely trivial to implement. No one is asking you for IE6 support (if they are, ignore them), but IE11 can do most things decently with minimal effort. As long as a browser is receiving mainstream support and the effort isn't too much, you should be at least minimally supporting it.
I’m saying this specifically about a piece of obsolete technology. Firefox is in no way obsolete, so the comparison is entirely inapplicable.
Polyfills are available for most things but they’re not trivial, and they have a meaningful cost in two axes: developer effort, and performance. Things like CSS Flex, CSS Grid, SVG, and ECMAScript 6+ functionality can all be made to work in IE (with a few exceptions, like grid auto placement), but only by making things heavier, typically for everyone. Other things that are really nice to be able to depend on like CSS Custom Properties and more recent ECMAScript syntax (e.g. modules) either can’t be used outright, or require much more extensive working around which still restricts what you can do in all the other browsers.
Speaking as someone who has had to maintain IE11 support for a couple of things within the last few years, it seriously is a real drain that contributes more code, bugs (not just for the offending browser) and simple complexity than many realise.
IE is not receiving mainstream support. The effort is too much. You should either ignore it, or, if people are trying to get support on specific issues in it, strongly consider actively scuppering it.
I observed this whitespace behaviour by accident maybe a year and a half ago (I think it was related to either CSS minification experiments or how Firefox’s dev tools didn’t cope at all well with empty or only-whitespace property declarations), and after a bit of poking and prodding figured out how to achieve exactly what this article describes, poor man’s if(). Since then I’ve seen a couple of others discover and report this independently as well, and I’m sure plenty of others have found it too. It’s always fun when you have a complex system and people stumble upon interesting emergent behaviour. I doubt that the CSS Custom Property spec writers had this sort of application in mind when they specified that it was whitespace-sensitive.
for those interested this "hack" is in extensive use in Tailwind css to control opacity for a host of color utilities https://tailwindcss.com/docs/opacity
This doesn’t look to be true. Opacity is straight `opacity: 0.5` and the likes (no custom properties involved) and its background and text opacity things use CSS Custom Properties (`--bg-opacity: 1` and `background: rgb(…, …, …, var(--bg-opacity))`), but not this technique which is all about using custom property values containing only whitespace.
> This is a declaration where the value of --foo is literally one space character.
I don't know if this is technically accurate though it leads to the same result. Whitespace in such languages is generally ignored - I believe this would just result in an empty property under the hood.
EDIT: also why the off-kilter background shapes for the code blocks. It made me dizzy reading the article.
Speaking bluntly: you don’t know what you’re talking about here (you’re talking in generalities without specific knowledge of how CSS is implemented), and Lea does (she’s very expert in this area).
Whitespace tokens are skipped, as I suspected. There is no whitespace value. As I mentioned before, the result of what the author describes is the same, but the explanation isn't entirely accurate. It's harmless errata.
Perhaps it is /you/ that doesn't know what they're talking about.
37 comments
[ 5.3 ms ] story [ 57.4 ms ] threadI am all for clever hacks but more needs to be done when it comes to explaining to experienced developers and new people exactly how to use CSS variables. It has been a difficult journey and we still have people doing their own weird things with LESS/SASS precompilers and not writing maintainable CSS.
Don't? They don't work in IE. By the time you've written a fallback you've complicated things just as much as Less/Sass would but without the benefits of those.
If you don’t have any evidence that you need to support it, I strongly recommend deliberately removing support for it, whether that means just not caring if it works or not or actively breaking it (though please implement that as an IE blacklist, not a certain-browsers whitelist). If you do have evidence that you need to support it, push to remove it, even if you can’t remove it just yet. If you can stop supporting IE, it will make your life easier and it will make my life easier.
Polyfills are available for most of the usual things and they're absolutely trivial to implement. No one is asking you for IE6 support (if they are, ignore them), but IE11 can do most things decently with minimal effort. As long as a browser is receiving mainstream support and the effort isn't too much, you should be at least minimally supporting it.
Polyfills are available for most things but they’re not trivial, and they have a meaningful cost in two axes: developer effort, and performance. Things like CSS Flex, CSS Grid, SVG, and ECMAScript 6+ functionality can all be made to work in IE (with a few exceptions, like grid auto placement), but only by making things heavier, typically for everyone. Other things that are really nice to be able to depend on like CSS Custom Properties and more recent ECMAScript syntax (e.g. modules) either can’t be used outright, or require much more extensive working around which still restricts what you can do in all the other browsers.
Speaking as someone who has had to maintain IE11 support for a couple of things within the last few years, it seriously is a real drain that contributes more code, bugs (not just for the offending browser) and simple complexity than many realise.
IE is not receiving mainstream support. The effort is too much. You should either ignore it, or, if people are trying to get support on specific issues in it, strongly consider actively scuppering it.
IE is dead. Let it stay dead.
https://news.ycombinator.com/item?id=23865900
https://github.com/propjockey/css-sweeper
> Space Toggle has been independently discovered a number of times
> @anatudor probably the first to discover it - about 3 years ago!
> @JamesOx57 in April 2020 which kickstarted development of augmented-ui v2 because it allows augs to be equipped without extra class names.
> @DavidKPiano in June 2020 and instead of just space, he includes an empty comment and calls it prop-and-lock
And now Lea Verou
Like a class?
I don't know if this is technically accurate though it leads to the same result. Whitespace in such languages is generally ignored - I believe this would just result in an empty property under the hood.
EDIT: also why the off-kilter background shapes for the code blocks. It made me dizzy reading the article.
https://www.w3.org/TR/css-syntax-3/#parse-rule
Whitespace tokens are skipped, as I suspected. There is no whitespace value. As I mentioned before, the result of what the author describes is the same, but the explanation isn't entirely accurate. It's harmless errata.
Perhaps it is /you/ that doesn't know what they're talking about.