Comment by themafia
18 hours ago
It's a great way to make conditional styles without having to use JavaScript; however, having used JS for years to make theme color and icon sets that rely on CSS properties, I'm not sure I particularly like this method. I feel like you have to smear a lot of logic across your CSS whereas with JS you can reduce your theme to a data structure and just have a simple function to setup all the CSS variables based on that.
Am I just an old man?
The primary goal is to just have a more concise way to do @media queries. Its not intended as a replacement for most uses of JS
If we've learned anything from the history of CSS, JS and the semantic web it is that 99% of the time a feature will be used in ways that were not intended. There is no reason to suppose that this will be any different.
You have to consider why, and the answer was often "there's no other way".
The paths of least resistance on the web are now very different. These features were not delayed due to implementation details, but a deliberate shepherding of the standards. The most powerful features were saved for later and even still this is scoped to media queries, etc. only.
I like making static informational pages and don't know the first thing about JavaScript, so this could be handy for me.
Javascript always suffer from FOUC problem though (Unless it's server side). Although the if() css function seems to just be syntax suger of standard @media query. So it doesn't really add anything to solve existing problems.
Edited: It seems it can also be toggled from css variable? So it might actually fix some existing problems.
How hard would it be to have a response header that tells the browser "don't display anything at all until we ask you to from JS when we're ready"?
Considering the kinds of crap that have been done with headers...
Would it be enough to have <body> hidden using an inline style in the initial html response and when everything is loaded, one would remove the style using javascript?
Many sites do something like that in practice. The problem is the extra 500ms of parse+eval time for your JS bundle influences user behavior a lot on the margin, so it’s better to not force the user to wait.
How hard would it be to use JS for progressive enhancement instead making your website depend on it to display simple text and images.
Practically only cordova does these for now. But it's a native app so of course it can do whatever it want.
You're pulling the old man card on CSS-in-JS? Putting your style logic in CSS is what CSS is for, CSS-in-JS is an annoying hack to make React work. What this is replacing is SCSS.
Well, historically, styles were first in JS (JS StyleSheets in Netscape 4.0) and were pulled out into CSS. – This is an old man card! ;-)
Just use SCSS to smear the logic across CSS automatically.
God forbid we use html5
There is no HTML5 other than a buzzword: https://html.spec.whatwg.org/dev/introduction.html#is-this-h...?