[{"_1":2,"_43":-5,"_44":-5},"loaderData",{"_3":4,"_42":-5},"routes/posts._index",[5,30],{"_6":7,"_8":9,"_10":11,"_12":13,"_14":15,"_16":17,"_18":19,"_20":21,"_24":25},"name","css-madness-to-hooks","markdown","\nIn the component era, the close relationship between HTML and CSS demands—from a\nmaintainability perspective at least—colocation. Some people still believe in a\n\"separation of concerns\"; but, as a pragmatist, I only see a technical boundary.\nOne that I, like many (most?) other React developers, would prefer didn't exist.\n\nThe most basic way to colocate HTML and CSS is rooted in the HTML standard\nitself in the form of the\n[`style` attribute](https://html.spec.whatwg.org/multipage/dom.html#the-style-attribute).\nWeb frameworks universally support the `style` attribute, and React even\nprovides an additional layer of \"syntactic sugar\" convenience known as\n[style objects](https://react.dev/learn/javascript-in-jsx-with-curly-braces#using-double-curlies-css-and-other-objects-in-jsx).\nIn short, the `style` attribute, often referred to as _inline styles_, \"just\nworks\". Natively.\n\nUnfortunately, some inherent \"feature gaps\" have made inline styles unsuitable\nfor most real-world use cases. Something as trivial as a\n[hover effect](https://stackoverflow.com/questions/131653/inline-style-to-act-as-hover-in-css)\ncan't be done with inline styles because they lack\n[pseudo-classes](https://www.w3.org/TR/selectors-4/#pseudo-classes). Responsive\ndesign is out of the question because they don't have\n[media](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries) or\n[container](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_container_queries)\nqueries. At some point, inline styles\n[were supposed to do more](https://www.w3.org/TR/2002/WD-css-style-attr-20020515#examples);\nbut, tragically, the browser vendors never delivered.\n\nToday, the simplicity of inline styles is easily outweighed by their\nlimitations, a situation that has fueled much resentment and pushed developers\ntoward heavy-handed workarounds like CSS-in-JS, atomic CSS, and \"zero-runtime\"\nsolutions (each one making different tradeoffs but accepting some form of\nsignificant complexity nevertheless). _CSS madness._\n\nPersonally, I've engaged in CSS madness for several years, even creating a few\nworkarounds of my own. But a recent discovery has dramatically changed the\nsituation for me.\n\nCSS Variables are programmable.\n\n## The fallback trick\n\nThe `var()` function, used to access the value of a variable, allows you to\nprovide a fallback value to use in case that variable isn't set. For example,\n`var(--error-color, red)` represents the value of `--error-color`, if set, or\notherwise the fallback value of `red`.\n\nThe programmability I mentioned is built upon this simple fallback mechanism.\n\nWhen the variable is set to `initial`, the fallback value is used instead.\n\nWhen the variable is set to an empty value, the empty value is used rather than\nthe fallback value. The empty value has no effect on the declaration.\n\nThus, a pair of variables can be used to toggle between arbitrary fallback\nvalues depending on some condition, like a matching selector or at-rule.\n\nArmed with this knowledge, you can do the unthinkable—implement a hover effect\nwithin an inline style:\n\n```html\n\n Hover me\n\n\n```\n\n[Live demo](https://htmlpreview.github.io/?https://github.com/nsaunders/writing/blob/master/posts/css-madness-to-hooks/demo.html)\n\nAs you can see, the mechanism is simple, but the syntax leaves much to be\ndesired:\n\n1. It is difficult to parse the value of the `color` declaration at a glance.\n\n2. Combining multiple \"state variables\" requires nesting, which is tedious and\n difficult to read. For example, activating a hover effect only when the\n element is enabled looks something like this:\n\n```css\ncolor: var(--enabled-on, var(--hover-on, #18659f) var(--hover-off, #003665)) var(\n --enabled-off,\n gray\n );\n```\n\nMoreover, the supporting style sheet, while compact and highly reusable, is\nstill just boilerplate that I'm sure you'd rather not have to maintain.\n\nBut don't worry—I can offer a solution that addresses all of these points,\nhelping to make this approach not only simple, but convenient.\n\n## Hooks (not the React kind)\n\nWhen I found the variable fallback trick, I was very excited about its potential\nas a solution to CSS madness. But it was also clear that the syntax was a big\nproblem. Some kind of abstraction would still be needed; but at least now it\ncould map cleanly to a simple underlying reality, rather than simply hiding\ncomplexity.\n\nSo, I set about building CSS Hooks, aiming to fill the feature gaps of the\n`style` prop to complete its otherwise unrivaled developer experience.\n\nA _hook_ allows you to tap into a CSS feature that is normally inaccessible\nwithin inline styles. The canonical first example is the `:hover` pseudo-class;\nbut the possibilities include the full range of pseudo-classes, media queries,\ncontainer queries, and even custom selectors.\n\n### Usage\n\nAnywhere you find a style object that you'd like to enhance with hooks, you can\nsimply \"wrap\" it in a call to the `css` function:\n\n```tsx\nfunction Button(props: Props) {\n return (\n \n );\n}\n```\n\nFrom there, it's possible to use the hooks via nested style objects. For\nexample, you might want to apply some declarations when the `hover` or\n`disabled` hooks are activated:\n\n```tsx\nfunction Button(props: Props) {\n return (\n \n );\n}\n```\n\nUsing the variable fallback trick, the `css` function flattens the style object,\nreducing it to a form that is compatible with the `style` prop.\n\n### Generating CSS\n\nAs you saw earlier when I demonstrated the variable fallback trick, it is\nsupported by a small static style sheet. The CSS Hooks system takes care of\ngenerating the content of that style sheet for you. All you need to worry about\nis adding it to the document, e.g. via a `

Latest post

From CSS madness to CSS Hooks

Worth a read

Function asChild