I write a lot of CSS, and for the most part that means I'm writing vanilla CSS manually (no preprocessors, no build step, no compiling, just CSS in an editor).
There are a number of techniques though that I wish I could use with CSS that CSS isn't powerful enough to reach:
parentNode in JS)previousElementSibling in JS)document.querySelector() in JS):has(), :focus-within)innerHTML or value in JS)<, >, ==, <=, >=offsetWidth)offsetHeight)innerHTML.length or value.length)children.length)scrollLeft or scrollTop)<select> element when emptyheight: 0 to height: autoe.clientX and e.clientY for mouse cursor, or e.touches[0].clientX and e.touches[0].clientY for touchscreen)minmax() or Math.min and Math.max)vw, vh but based on percentages of an element's own offsetWidth or offsetHeight)<iframe> scalable without a wrapper or padding<textarea> or <input> auto-expand to contentsIf I want to style any of the things above my options are:
So these should all be things that CSS-in-JS should make possible. The question shouldn't be: "Should we use CSS-in-JS over writing CSS for these styles?", but rather: "Should we use CSS-in-JS over writing JS for these styles?"
However, having said all that I still haven't had a single client project using React, Vue, Ember, or any of these other frameworks where CSS-in-JS is common. So what use is it to me? If I can't use CSS-in-JS to style the WordPress site my client has and needs work on, it's useless to me. If I can't use CSS-in-JS for the custom CMS a client has built themselves (PHP-based, not Node) then I'm back at the start, having to write custom JavaScript for all of these techniques I might want to use.
This is where JS-in-CSS comes in! (Also called: CSS Reprocessors)
I much prefer the idea of using JS to reprocess CSS styles as often as needed after the page has loaded. This allows you to author CSS (with some extra features for JS to read) and then apply that JS-powered-CSS to any HTML, regardless of how the HTML got there. You don't need React, or a certain framework, or workflow. It could be as simple as writing:
<div id=eqcss>EQCSS Element Query</div>
<style>
@element #eqcss and (min-width: 500px) {
$this { background: lime }
}
</style>
<script src=http://eqcss.com/EQCSS.js></script>
Or, to build the equivalent demo using a totally different CSS Reprocessor:
<div id=cssplus>CSSplus Element Query</div>
<style>
#cssplus[test="this.offsetWidth > 500"] {
background: lime;
}
</style>
<script src=http://csspl.us/selectory.js></script>
There's an example of an 'element query' technique written in two different JS-in-CSS dialects: EQCSS and CSSplus. This is something CSS can't normally do — to set a responsive breakpoint on an element that triggers when that element is wider than 500px. Here in our example we have a tiny bit of HTML (and it doesn't matter what tool was used to write this HTML) one CSS rule, and a link to the JavaScript plugin that makes it work. Notice there's no build step, your HTML doesn't need to be processed — you can just write the HTML however you want, write the JS-in-CSS however you want, then it works when you view it live :D
I think JS-in-CSS (not CSS-in-JS) is the right abstraction to accomplish the long list of techniques I wish CSS could reach :D