I was killing some time browsing my CodePen feed for some eye candy and didn’t need to go past the first page before spotting a neat CSS hover effect by Adam Argyle.
I must’ve spent 10 minutes just staring at the demo in awe. There’s something about this that feels so app-like. I think it might be how contextually accurate it is in that the background color slides in from the left, then exits out through the right. It’s exactly the sort of behavior I’d expect from a mouse-in, mouse-out sort of interaction.
Whatever the case, I fired up a fresh pen and went to work recreating it. And it’s not super complex or anything, but rather a clever use of transitions and transforms paired with proper offsets. Quite elegant! I’m actually a little embarrassed how long it took me to realize how the mouse-out part works.
Here’s how I tackled it, warts and all.
“I bet that’s using a transition on a background.”
That was my first thought. Define the background-color, set the background-size and background-position, then transition the background-position. That’s how I’ve seen that “growing” background color thing done in the past. I’ve done that myself on some projects, like this:
If I could do the same thing, only from left-to-right, then all that’s left is the mouse-out, right? Nope. The problem is there’s nothing that can really make the background-position transition from left-to-right to left-to-right. I could make it do one or the other, but not both.
“Maybe it’s a transform instead.”
My next attempt was jump into transforms. The transform property provides a bunch of functions that can transition together for slightly more complex movement. For example, the background can “grow” or “shrink” by changing the element’s scale(). Or, in this case, just along the x-axis with scaleX().
But like I mentioned, there isn’t a way to isolate the element’s background to do that. Going from scaleX(0) to scaleX(1) scales the entire element, so that basically squishes the link — content and all — down to nothing, then stretches it back out to its natural size which is a totally different effect. Plus, it means starting with scaleX(0) which hides the whole dang thing by default making it unusable.
But a pseudo-element could work! It doesn’t matter if that gets squished or hidden because it isn’t part of the actual content. Gotta put the background on that instead and position it directly under the link.
a {
/* Keeps the pseudo-element contained to the element */
position: relative;
}
a::before {
background: #ff9800;
content: "";
inset: 0; /* Logical equivalent to physical offsets */
position: absolute;
transform: scaleX(0); /* Hide by default */
z-index: -1; /* Ensures the link is stacked on top */
}
“Now I need ::before to change on hover.”
I knew I could make ::before scale from 0 to 1 by chaining it to the link element’s :hover state.
a:hover::before {
transform: scaleX(1)
}
Nice! I was onto something.
Sprinkle a little transition fairy dust on it and things start to come to life.
Again, this is where I sorta got stuck. Something in my head just wasn’t clicking for some reason. As per usual, I ran over to the CSS-Tricks Almanac to see what property might’ve slipped my mind.
Ah, yes. That would be transform-origin. That allows me to set where the transform starts, which is not totally dissimilar from setting the background-position like I tried earlier. The transform could start from the left instead of its default 50% 50% position.
I was already transitioning ::before to scaleX(1) on link hover. If I reversed the transform-origin from left to right at the same time, then mayyyybe the highlight goes out the opposite of how it came in when the mouse exits?
I took a break from work and started some small, personal projects (toys). One of those small projects is potato.horse where I keep all of my doodles, visual short stories and jokes. Check it out!
However, this post is not about my break from work, other experiments, or the site itself. People seem to like one particular technique I used in the design, notably, the background effect applied that transitions between colors when the user browses the content:
Some asked me how this effect was implemented (including going as far as reading the minified code, which is very flattering).
So, here’s a quick gist, followed up with some context:
In short, I map the scroll position into the hue in the HSL color notation. Let’s break this down.
Color models
There are many ways of describing colors in CSS, with the two most common ones being RGB (left) and HSL (right):
RGB is an additive color palette. This means that mixing 100% of red, green and blue produces white, mixing 100% red and 100% green but 0% blue produces yellow, and so on. This is different from, say, using oil paint or the CMYK color model, where the resulting tone would be black(-ish)1.
We’re used to this approach because it’s easy to describe in code, but specifying colors in terms of hue, saturation and luminosity seems more natural, especially if you come from a design background, or… you know, are a human being using a human language.
We’ve gotten used to RGB as developers, but in spoken language, using it would feel unnatural and confusing. Façade would be very hard to use in RGB.
On the other hand, HSL can often be much more intuitive to work with. For instance, if I want to make a color slightly colder, I can just move the hue slider a bit towards blue and I should get closer to what I have in mind. With RGB, if we make the color appear colder by including more blue, the resulting tone will be a bit brighter as the blue component contributes to the overall lightness. This means that you’d have to lower the red and green values to compensate.
To see how this works in practice, try maxing out the blue color in the example below.
The first thing that stands out is that all tones are shifted towards blue and the overall brightness of the picture is increased. In the case of the effect we’re discussing, that would be undesirable.
Now, let’s try to do the same with the HSL color circle. Drag the slider to the left, by ca. 90 degrees:
In this scenario, using HSL not only turns Susan into a vampire, but also maintains a similar2 level of brightness. And that’s exactly what I’m looking for.
So, what I mean by saying this:
How does this work? In short, I map the scroll position into the hue in the HSL color notation. Rafal, 2 days earlier
…is that that every time we detect a scroll event, I try to map it to an angle on the hue circle:
I didn’t want to start with red as it would make me hungry and the base yellow fits the design a bit better, so I applied a small initial shift—hence const from = 51 set as the initial offset.
And, as far as the basic implementation goes, that’s it!
Now, there are three other areas of improvement.
useRainbow performance
We’re triggering a repaint on every scroll, so I was a bit worried that older mobile devices, or even some hi-end laptops plugged in to 4k screens might not be able to maintain solid 60fps. But, I’m happy with the results so far. Using passive event listeners provided a bit of a boost, especially on mobile.
If I realize that performance is a problem, especially with more content down the line, I’ll probably focus on:
removing the unnecessary call to getBoundingClientRect on every scroll handler call, and
deferring or throttling background color changes using requestAnimationFrame.
I expect the first improvement to have some impact, but the benefits of the second one should be negligible.
Measure before optimizing. Obsessing about the performance only makes sense when issues become noticeable, be it through a drop in framerate or battery impact. Your iPhone Pro has more computing power than many low-end laptops, so it’s a good idea to test on those devices too. It’s good to have a crappy old Android phone exacly for that purpose if you can spare a few quid.
Perceptually uniform color spaces
You might’ve noticed that in the previous illustrations some fully saturated colors seemed darker than others. That’s because the color spaces we normally use when coding don’t reflect the way the human eye works. I’ll leave the in-depth explanation to someone much more experienced than me, but suffice to say (gross oversimplification alert!) that, generally, the same amount of red/green/yellow will appear brighter than blue. This means that in some cases the text on the page will be harder to read.
For now, this isn’t an issue as I’ve just put this thing online and titles serve a secondary purpose. But there’s a solution to the problem and it’s not overly complicated: use a perceptually uniform color space. There’s a bunch of libraries that do it out of the box, both in JavaScript/TypeScript and CSS/Sass/<pick your CSS flavor here>. hsluv seems like a good starting point.
Accessiblity
Note that I’ll be focusing on the visual effect itself and not discussing the rest of the site (e.g. alt tags, document structure, etc…). I’d like to focus on contrast, color blindness and people who rely on prefers-reduced-motion. The site is a living document; there’s always so much to improve. For instance, contrast can be an issue in a few, non-critical places. I’m happy to accept feedback and implement it: hit me up!.
color blindness
I wanted to make sure that the effect doesn’t break the site completely for people with color blindness. So I focused on the most common types: deuteranomaly and protanomaly (red-green color blindness), but also ran wider tests. I used Photoshop and Colorblindly (Chrome extension) for some rudimentary checks.
prefers-reduced-motion
The prefers-reduced-motion CSS media feature is used to detect if the user has requested that the system minimize the amount of non-essential motion it uses.
This site doesn’t contain many animations (besides the Little Sausage Angels you’ll see if you hit “Share”), but I was wondering if people who rely on prefers-reduced-motion would like the background color to stay constant.
The short answer is: I don’t know. My intuition is that rotating colors don’t really qualify as motion, but my experience and understanding of the problem is, to say the least, limited. In situations like this, I’d rather depend on user research than guesses.
Luckily, the site had its five minutes of fame on Reddit which proved to be a decent opportunity to collect feedback. None of the users brought up an issue with the background effect so far. I’m also lucky enough to know a bunch of accessibility specialists, such as Sandrina Pereira. Her suggestion was that (a) background animations definitely qualify as motion, and (b) perhaps the effect feels natural because it’s a direct result of a user interaction.
Summary
The late-90s Geocities web felt playful and weird. It was fun in an uninhibited, somewhat less performative, way. I wanted to incorporate some of this look and feel in the site. But still, I didn’t want to make it feel esoteric to the point where you’d need to up your hipsterdom-level to 9000 and browse it exclusively throught Netscape 7. All of that, while listening to the new Nirvana Unplugged album.
I still wanted decent UX on mobile and desktop, and some space for easter eggs (something you can’t do when living in the strange and abusive relationship with social media we’ve grown so accustomed to).
As a kid, I had built six websites before I even got access to the Internet for the first time. Now, after being burned out for three years, even considering changing my job, it was the first time I genuinely enjoyed coding. I forgot how much fun it was!
You conditionally load it when you detect the browser doesn’t support Container Queries.
You write CSS as you normally would, including current-spec-compliant Container Queries syntax code.
It just works.
It’s pretty great to have a container query polyfill that is this easy to use and from Chrome itself, the first-movers as far as early test implementations. Looks like Surma put it together — thanks Surma!
There was a Container Query polyfill from Jonathan Neal called cqfill that predates this. I’m not sure if it’s officially deprecated, but it required extra non-spec CSS to work and PostCSS processing, so I’d consider it deprecated in favor of this newer polyfill.
Loading the polyfill is like this:
// Support Test
const supportsContainerQueries = "container" in document.documentElement.style;
// Conditional Import
if (!supportsContainerQueries) {
import("https://cdn.skypack.dev/container-query-polyfill");
}
You can pull it from npm or use as a <script>, but this way seems best to me to keep things light and easy.
Then you’re free to use the syntax for a container query in CSS. Say you have a weather widget in HTML. You’ll need an extra wrapper element for your queries. That’s just the rule: you can’t query the thing you style.
Here’s that slightly more fleshed-out demo of the Container Query polyfill using an actual weather widget:
I first saw this over on Bramus’ blog, and he’s got a classic card demo going with this Container Query polyfill. Scroll up and down. You’ll see a row of bear cards at the top (if your browser window is wide enough), and then similar bear cards in different layout positions below that change into nicer formats when they can, based on the container query.
The polyfill relies on ResizeObserver, MutationObserver and :is(). Therefore, it should work in all modern browsers, specifically Chrome/Edge 88+, Firefox 78+ and Safari 14+.
There are all sorts of other minor little caveats covered in those docs, including what it does and doesn’t support. Seems like mostly niche stuff to me — the main/typical use cases are covered.
A game changer?
As I write, we’ve seen behind-flag support for Container Queries in Chrome, and it is an official spec draft now:
Today's CSSWG call:
🥳 First Public Working Draft of Contain Level 3 (container queries)
🥳 FPWD of Cascade Level 6 (scope)
This means the proposals have graduated to being official work-in-progress specifications. Still a lot to do before browsers ship, but it's a big step!
That’s extremely exciting and points heavily toward browsers actually shipping with Container Queries, even if the syntax changes a bit on the way (it already has a number of times). But, of course, we have no idea if/when Container Queries do ship — and when that magical threshold is crossed, we also don’t know where we can use them without much worry, like we can with flexbox and grid now.
That “just use it” date is probably a decent ways off, but if you’re into the idea of polyfilling and being careful with progressive enhancement, I’d say the date for using Container Queries could be right now-ish. Looks to me like the polyfill script comes across the wire at 2.8kb, so it’s fairly trivial in size for something so important.
I suspect this polyfill will skyrocket usage of Container Queries in this coming year.
FOUC?
The fact that your styles only correctly apply after a JavaScript file is downloaded and executed puts sites into Flash of Unstyled Content (FOUC) territory. Here’s a video recording where I can see it on my own demo. I’m not sure there is a way around this other than intentionally delaying rendering, which is generally considered a no-no. Similar to loading web fonts, FOUC is probably a good thing as it means your content is never hidden or delayed, even if the shifts aren’t ideal. The FOUC should go away once browser support lands and the polyfill stops loading at all.
Have fun polyfilling container queries! I’d love to see more demos of it.
I was working on a client project a few days ago and wanted to create a certain effect on an <img>. See, background images can do the effect I was looking for somewhat easily with background-attachment: fixed;. With that in place, a background image stays in place—even when the page scrolls. It isn’t used all that often, so the effect can look unusual and striking, especially when used sparingly.
It took me some time to figure out how to achieve the same effect only with an inline image, rather than a CSS background image. This is a video of the effect in action:
The exact code for the above demo is available in this Git repo. Just note that it’s a Next.js project. We’ll get to a CodePen example with raw HTML in a bit.
Why use <img> instead of background-image?
The are a number of reasons I wanted this for my project:
It’s easier to lazy load (e.g. <img loading="lazy"… >.
It provides better SEO (not to mention accessibility), thanks to alt text.
It’s possible to use srcset/sizes to improve the loading performance.
It’s possible to use the <picture> tag to pick the best image size and format for the user’s browser.
It allows users to download save the image (without resorting to DevTools).
Overall, it’s better to use the image tag where you can, particularly if the image could be considered content and not decoration. So, I wound up landing on a technique that uses CSS clip-path. We’ll get to that in a moment, right after we first look at the background-image method for a nice side-by-side comparison of both approaches.
1. Using CSS background-image
This is the “original” way to pull off a fixed scrolling effect. Here’s the CSS:
But as we just saw, this approach isn’t ideal for some situations because it relies on the CSS background-image property to call and load the image. That means the image is technically not considered content—and thus unrecognized by screen readers. If we’re working with an image that is part of the content, then we really ought to make it accessible so it is consumed like content rather than decoration.
Otherwise, this technique works well, but only if the image spans the whole width of the viewport and/or is centered. If you have an image on the right or left side of the page like the example, you’ll run into a whole number of positioning issues because background-position is relative to the center of the viewport.
Fixing it requires a few media queries to make sure it is positioned properly on all devices.
2. Using the clip-path trick on an inline image
Someone on StackOverflow shared this clip-path trick and it gets the job done well. You also get to keep using the<img> tag, which, as we covered above, might be advantageous in some circumstances, especially where an image is part of the content rather than pure decoration.
Now, before we rush out and plaster this snippet everywhere, it has its own set of downsides. For example, the code feels a bit lengthy to me for such a simple effect. But, even more important is the fact that working with clip-path comes with some implications as well. For one, I can’t just slap a border-radius: 10px; in there like I did in the earlier example to round the image’s corners. That won’t work—it requires making rounded corners from the clipping path itself.
Another example: I don’t know how to position the image within the clip-path. Again, this might be a matter of knowing clip-path really well and drawing it where you need to, or cropping the image itself ahead of time as needed.
Is there something better?
Personally, I gave up on using the fixed scrolling effect on inline images and am back to using a CSS background image—which I know is kind of limiting.
Have you ever tried pulling this off, particularly with an inline image, and managed it well? I’d love to hear!
We’re in something of a new era of CSS resets where… you kind of don’t need one? There isn’t that many major differences between browsers on default styling, and by the time you’re off and running styling stuff, you’ve probably steamrolled things into place. And so perhaps “modern” CSS resets are more of a collection of opinionated default styles that do useful things that you want on all your new projects because, well, that’s how you roll.
Looking through Josh’s choices, that’s what it seems like to me: a collection of things that aren’t particularly opinionated about design, but assist the design by being things that pretty much any project will want.
I’m gonna go through it and toss out 🔥 flamin’ hot opinions.
Heck yes. We used to consider this a global holiday ’round here. Although, with more and more layout being handled by grid and flexbox, I’m feeling like this is slightly less useful these days. When you’re setting up a layout with fr units and flexin’ stuff, the box-sizing model doesn’t come into play all that much, even when padding and border are involved. But hey, I still prefer it to be in place. I do think if it goes into a CSS reset it should use the inheritance model though, as it’s easier to undo on a component that way.
* {
margin: 0;
}
This is basically why the CSS-Tricks logo “star” exists. I used to love this little snippet in my CSS resets. There was a period where it started to feel heavy-handed, but I think I’m back to liking it. I like how explicit you have to be when applying any margin at all. Personally, I’d rock padding: 0; too, as list elements tend to have some padding pushing them around. If you’re nuking spacing stuff, may as well nuke it all.
html, body {
height: 100%;
}
Probably a good plan. Josh says “Allow percentage-based heights in the application,” which I can’t say comes up much in my day-today, but what it does is stuff like the body background not filling the space the way you might expect it to.
body {
line-height: 1.5;
-webkit-font-smoothing: antialiased;
}
I can’t get into the -webkit-font-smoothing: antialiased; thing. I think it tends to make type dramatically thin and I don’t love it. I don’t mind it as a tool, but I wouldn’t globally apply it on all my projects.
I also generally like to put global typographic sizing stuff on the html selector instead, just because the “root” part of rem implies the <html> element — not the <body> — and I like sizing stuff in rem and then adjusting the root font-size at the root level in media queries.
That 1.5 value feels like a good default line-height (more of a 1.4 guy myself, but I’d rather go up than down). But as soon as it’s set, I feel magnetically pulled into reducing it for heading elements where it’s always too much. That could happen via h1, h2, h3 kinda selectors (maybe h4–h6 don’t need it), but Josh has some CSS trickery at work with this snippet that didn’t make it into the final reset:
* {
line-height: calc(1em + 0.5rem);
}
That’s clever in how the 0.5rem goes a long way for small type, but isn’t as big of an influence for large type. I could see trying that on a greenfield project. Prior art here is by Jesús Ricarte in “Using calc to figure out optimal line-height.”
Good move for a CSS reset. The block display type there prevents those annoying line-height gaps that always kill me. And you almost never want any of these media blocks to be wider than the parent. I somehow don’t think picture is necessary, though, as it’s not really a style-able block? Could be wrong. I’d probably toss iframe and object in there as well.
Good move for sure. It’s bad news when a long word (like a URL) forces an element wide and borks a layout. I tend to chuck this on something — like article or .text-content or something — and let it cascade into that whole area (which would also catch text that happens to be contained in an improper element), but I don’t mind seeing it on specific text elements.
If doing that, you probably wanna chuck li, dl, dt, blockquote on that chain. Despite having attempted to research this several times (here’s a playground), I still don’t 100% know what the right cocktail of line-wrapping properties is best to use. There is word-break: break-word; that I think is basically the same thing. And I think it’s generally best to use hyphens: auto; too… right??
#root, #__next {
isolation: isolate;
}
I don’t quite understand what’s happening here. I get that this is a React/Next thing where you mount the app to these roots, and I get that it makes a stacking context, I just don’t get why it’s specifically useful to have that stacking context at this level. At the same time, I also don’t see any particular problem with it.
All in all — pretty cool! I always enjoy seeing what other people use (and go so far as to suggest) for CSS resets.
Your mission — should you decide to accept it — is to build a Button component in four frameworks, but, only use one button.css file!
This idea is very important to me. I’ve been working on a component library called AgnosticUI where the purpose is building UI components that aren’t tied to any one particular JavaScript framework. AgnosticUI works in React, Vue 3, Angular, and Svelte. So that’s exactly what we’ll do today in this article: build a button component that works across all these frameworks.
The source code for this article is available on GitHub on the the-little-button-that-could-series branch.
We’re going to set up a tiny Yarn workspaces-based monorepo. Why? Chris actually has a nice outline of the benefits in another post. But here’s my own biased list of benefits that I feel are relevant for our little buttons endeavor:
Coupling
We’re trying to build a single button component that uses just one button.css file across multiple frameworks. So, by nature, there’s some purposeful coupling going on between the various framework implementations and the single-source-of-truth CSS file. A monorepo setup provides a convenient structure that facilitates copying our single button.css component into various framework-based projects.
Workflow
Let’s say the button needs a tweak — like the “focus-ring” implementation, or we screwed up the use of aria in the component templates. Ideally, we’d like to correct things in one place rather than making individual fixes in separate repositories.
Testing
We want the convenience of firing up all four button implementations at the same time for testing. As this sort of project grows, it’s safe to assume there will be more proper testing. In AgnosticUI, for example, I’m currently using Storybook and often kick off all the framework Storybooks, or run snapshot testing across the entire monorepo.
I believe the monorepo is particularly useful when all packages are coded in the same programming language, tightly coupled, and relying on the same tooling.
Setting up
Time to dive into code — start by creating a top-level directory on the command-line to house the project and then cd into it. (Can’t think of a name? mkdir buttons && cd buttons will work fine.)
First off, let’s initialize the project:
$ yarn init
yarn init v1.22.15
question name (articles): littlebutton
question version (1.0.0):
question description: my little button project
question entry point (index.js):
question repository url:
question author (Rob Levin):
question license (MIT):
question private:
success Saved package.json
That gives us a package.json file with something like this:
{
"name": "littlebutton",
"version": "1.0.0",
"description": "my little button project",
"main": "index.js",
"author": "Rob Levin",
"license": "MIT"
}
Creating the baseline workspace
We can set the first one up with this command:
mkdir -p ./littlebutton-css
Next, we need to add the two following lines to the monorepo’s top-level package.json file so that we keep the monorepo itself private. It also declares our workspaces:
Now descend into the littlebutton-css directory. We’ll again want to generate a package.json with yarn init. Since we’ve named our directory littlebutton-css (the same as how we specified it in our workspaces in package.json) we can simply hit the Return key and accept all the prompts:
$ cd ./littlebutton-css && yarn init
yarn init v1.22.15
question name (littlebutton-css):
question version (1.0.0):
question description:
question entry point (index.js):
question repository url:
question author (Rob Levin):
question license (MIT):
question private:
success Saved package.json
At this point, the directory structure should look like this:
We’ve only created the CSS package workspace at this point as we’ll be generating our framework implementations with tools like vite which, in turn, generate a package.json and project directory for you. We will have to remember that the name we choose for these generated projects must match the name we’ve specified in the package.json for our earlier workspaces to work.
Baseline HTML & CSS
Let’s stay in the ./littlebutton-css workspace and create our simple button component using vanilla HTML and CSS files.
And, just so we have something visual to test, we can add a little color in ./css/button.css:
.btn {
color: hotpink;
}
Now open up that index.html page in the browser. If you see an ugly generic button with hotpink text… success!
Framework-specific workspaces
So what we just accomplished is the baseline for our button component. What we want to do now is abstract it a bit so it’s extensible for other frameworks and such. For example, what if we want to use the button in a React project? We’re going to need workspaces in our monorepo for each one. We’ll start with React, then follow suit for Vue 3, Angular, and Svelte.
React
We’re going to generate our React project using vite, a very lightweight and blazingly fast builder. Be forewarned that if you attempt to do this with create-react-app, there’s a very good chance you will run into conflicts later with react-scripts and conflicting webpack or Babel configurations from other frameworks, like Angular.
To get our React workspace going, let’s go back into the terminal and cd back up to the top-level directory. From there, we’ll use vite to initialize a new project — let’s call it littlebutton-react — and, of course, we’ll select react as the framework and variant at the prompts:
$ yarn create vite
yarn create v1.22.15
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
[4/4] 🔨 Building fresh packages...
success Installed "create-vite@2.6.6" with binaries:
- create-vite
- cva
✔ Project name: … littlebutton-react
✔ Select a framework: › react
✔ Select a variant: › react
Scaffolding project in /Users/roblevin/workspace/opensource/guest-posts/articles/littlebutton-react...
Done. Now run:
cd littlebutton-react
yarn
yarn dev
✨ Done in 17.90s.
We initialize the React app with these commands next:
cd littlebutton-react
yarn
yarn dev
With React installed and verified, let’s replace the contents of src/App.jsx to house our button with the following code:
Now we’re going to write a small Node script that copies our littlebutton-css/css/button.css right into our React application for us. This step is probably the most interesting one to me because it’s both magical and ugly at the same time. It’s magical because it means our React button component is truly deriving its styles from the same CSS written in the baseline project. It’s ugly because, well, we are reaching up out of one workspace and grabbing a file from another. ¯\_(ツ)_/¯
Add the following little Node script to littlebutton-react/copystyles.js:
Let’s place a node command to run that in a package.json script that happens before the dev script in littlebutton-react/package.json. We’ll add a syncStyles and update the dev to call syncStyles before vite:
Now, anytime we fire up our React application with yarn dev, we’ll first be copying the CSS file over. In essence, we’re “forcing” ourselves to not diverge from the CSS package’s button.css in our React button.
But we want to also leverage CSS Modules to prevent name collisions and global CSS leakage, so we have one more step to do to get that wired up (from the same littlebutton-react directory):
touch src/button.module.css
Next, add the following to the new src/button.module.css file:
.btn {
composes: btn from './button.css';
}
I find composes (also known as composition) to be one of the coolest features of CSS Modules. In a nutshell, we’re copying our HTML/CSS version of button.css over wholesale then composing from our one .btn style rule.
With that, we can go back to our src/App.jsx and import the CSS Modules styles into our React component with this:
Whew! Let’s pause and try to run our React app again:
yarn dev
If all went well, you should see that same generic button, but with hotpink text. Before we move on to the next framework, let’s move back up to our top-level monorepo directory and update its package.json:
Run the yarn command from the top-level directory to get the monorepo-hoisted dependencies installed.
The only change we’ve made to this package.json is a new scripts section with a single script to start the React app. By adding start:react we can now run yarn start:react from our top-level directory and it will fire up the project we just built in ./littlebutton-react without the need for cd‘ing — super convenient!
We’ll tackle Vue and Svelte next. It turns out that we can take a pretty similar approach for these as they both use single file components (SFC). Basically, we get to mix HTML, CSS, and JavaScript all into one single file. Whether you like the SFC approach or not, it’s certainly adequate enough for building out presentational or primitive UI components.
Vue
Following the steps from vite’s scaffolding docs we’ll run the following command from the monorepo’s top-level directory to initialize a Vue app:
yarn create vite littlebutton-vue --template vue
This generates scaffolding with some provided instructions to run the starter Vue app:
cd littlebutton-vue
yarn
yarn dev
This should fire up a starter page in the browser with some heading like “Hello Vue 3 + Vite.” From here, we can update src/App.vue to:
:class="classes" is using Vue’s binding to call the computed classes method.
The classes method, in turn, is utilizing CSS Modules in Vue with the this.$style.btn syntax which will use styles contained in a <style module> tag.
For now, we’re hardcoding color: slateblue simply to test that things are working properly within the component. Try firing up the app again with yarn dev. If you see the button with our declared test color, then it’s working!
Now we’re going to write a Node script that copies our littlebutton-css/css/button.css into our Button.vue file similar to the one we did for the React implementation. As mentioned, this component is a SFC so we’re going to have to do this a little differently using a simple regular expression.
Add the following little Node.js script to littlebutton-vue/copystyles.js:
const fs = require("fs");
let css = fs.readFileSync("../littlebutton-css/css/button.css", "utf8");
const vue = fs.readFileSync("./src/components/Button.vue", "utf8");
// Take everything between the starting and closing style tag and replace
const styleRegex = /<style module>([\s\S]*?)<\/style>/;
let withSynchronizedStyles = vue.replace(styleRegex, `<style module>\n${css}\n</style>`);
fs.writeFileSync("./src/components/Button.vue", withSynchronizedStyles, "utf8");
There’s a bit more complexity in this script, but using replace to copy text between opening and closing style tags via regex isn’t too bad.
Now let’s add the following two scripts to the scripts clause in the littlebutton-vue/package.json file:
Now run yarn syncStyles and look at ./src/components/Button.vue again. You should see that our style module gets replaced with this:
<style module>
.btn {
color: hotpink;
}
</style>
Run the Vue app again with yarn dev and verify you get the expected results — yes, a button with hotpink text. If so, we’re good to move on to the next framework workspace!
Svelte
Per the Svelte docs, we should kick off our littlebutton-svelte workspace with the following, starting from the monorepo’s top-level directory:
npx degit sveltejs/template littlebutton-svelte
cd littlebutton-svelte
yarn && yarn dev
Confirm you can hit the “Hello World” start page at http://localhost:5000. Then, update littlebutton-svelte/src/App.svelte:
<script>
import Button from './Button.svelte';
</script>
<main>
<Button>Go</Button>
</main>
Also, in littlebutton-svelte/src/main.js, we want to remove the name prop so it looks like this:
import App from './App.svelte';
const app = new App({
target: document.body
});
export default app;
And finally, add littlebutton-svelte/src/Button.svelte with the following:
One last thing: Svelte appears to name our app: "name": "svelte-app" in the package.json. Change that to "name": "littlebutton-svelte" so it’s consistent with the workspaces name in our top-level package.json file.
Once again, we can copy our baseline littlebutton-css/css/button.css into our Button.svelte. As mentioned, this component is a SFC, so we’re going to have to do this using a regular expression. Add the following Node script to littlebutton-svelte/copystyles.js:
Now run yarn syncStyles && yarn dev. If all is good, we once again should see a button with hotpink text.
If this is starting to feel repetitive, all I have to say is welcome to my world. What I’m showing you here is essentially the same process I’ve been using to build my AgnosticUI project!
Angular
You probably know the drill by now. From the monorepo’s top-level directory, install Angular and create an Angular app. If we were creating a full-blown UI library we’d likely use ng generate library or even nx. But to keep things as straightforward as possible we’ll set up a boilerplate Angular app as follows:
npm install -g @angular/cli ### unless you already have installed
ng new littlebutton-angular ### choose no for routing and CSS
? Would you like to add Angular routing? (y/N) N
❯ CSS
SCSS [ https://sass-lang.com/documentation/syntax#scss ]
Sass [ https://sass-lang.com/documentation/syntax#the-indented-syntax ]
Less [ http://lesscss.org ]
cd littlebutton-angular && ng serve --open
With the Angular setup confirmed, let’s update some files. cd littlebutton-angular, delete the src/app/app.component.spec.ts file, and add a button component in src/components/button.component.ts, like this:
import { Component } from '@angular/core';
@Component({
selector: 'little-button',
templateUrl: './button.component.html',
styleUrls: ['./button.component.css'],
})
export class ButtonComponent {}
Add the following to src/components/button.component.html:
<button class="btn">Go</button>
And put this in the src/components/button.component.css file for testing:
.btn {
color: fuchsia;
}
In src/app/app.module.ts:
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';
import { ButtonComponent } from '../components/button.component';
@NgModule({
declarations: [AppComponent, ButtonComponent],
imports: [BrowserModule],
providers: [],
bootstrap: [AppComponent],
})
export class AppModule {}
Next, replace src/app/app.component.ts with:
import { Component } from '@angular/core';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css'],
})
export class AppComponent {}
Then, replace src/app/app.component.html with:
<main>
<little-button>Go</little-button>
</main>
With that, let’s run yarn start and verify our button with fuchsia text renders as expected.
Again, we want to copy over the CSS from our baseline workspace. We can do that by adding this to littlebutton-angular/copystyles.js:
[…] the behavior of shadow DOM by preprocessing (and renaming) the CSS code to effectively scope the CSS to the component’s view.
This basically means we can literally copy over button.css and use it as-is.
Finally, update the package.json file by adding these two lines in the scripts section:
"start": "yarn syncStyles && ng serve",
"syncStyles": "node copystyles.js",
With that, we can now run yarn start once more and verify our button text color (which was fuchsia) is now hotpink.
What have we just done?
Let’s take a break from coding and think about the bigger picture and what we’ve just done. Basically, we’ve set up a system where any changes to our CSS package’s button.css will get copied over into all the framework implementations as a result of our copystyles.js Node scripts. Further, we’ve incorporated idiomatic conventions for each of the frameworks:
SFC for Vue and Svelte
CSS Modules for React (and Vue within the SFC <style module> setup)
ViewEncapsulation for Angular
Of course I state the obvious that these aren’t the only ways to do CSS in each of the above frameworks (e.g. CSS-in-JS is a popular choice), but they are certainly accepted practices and are working quite well for our greater goal — to have a single CSS source of truth to drive all framework implementations.
If, for example, our button was in use and our design team decided we wanted to change from 4px to 3pxborder-radius, we could update the one file, and any separate implementations would stay synced.
This is compelling if you have a polyglot team of developers that enjoy working in multiple frameworks, or, say an offshore team (that’s 3× productive in Angular) that’s being tasked to build a back-office application, but your flagship product is built in React. Or, you’re building an interim admin console and you’d love to experiment with using Vue or Svelte. You get the picture.
Finishing touches
OK, so we have the monorepo architecture in a really good spot. But there’s a few things we can do to make it even more useful as far as the developer experience goes.
Better start scripts
Let’s move back up to our top-level monorepo directory and update its package.jsonscripts section with the following so we can kick any framework implementation without cd‘ing:
We can also provide a better set of baseline styles for the button so it starts from a nice, neutral place. Here’s what I did in the littlebutton-css/css/button.css file.
Let’s test this out! Fire up each of the four framework implementations with the new and improved start scripts and confirm the styling changes are in effect.
One CSS file update proliferated to four frameworks — pretty cool, eh!?
Set a primary mode
We’re going to add a mode prop to each of our button’s and implement primary mode next. A primary button could be any color but we’ll go with a shade of green for the background and white text. Again, in the baseline stylesheet:
There we go! Some developer conveniences and better baseline styles!
Updating each component to take a mode property
Now that we’ve added our new primary mode represented by the .btn-primary class, we want to sync the styles for all four framework implementations. So, let’s add some more package.json scripts to our top level scripts:
Be sure to respect JSON’s comma rules! Depending on where you place these lines within your scripts: {...}, you’ll want to make sure there are no missing or trailing commas.
Go ahead and run the following to fully synchronize the styles:
Running this doesn’t change anything because we haven’t applied the primary class yet, but you should at least see the CSS has been copied over if you go look at the framework’s button component CSS.
React
If you haven’t already, double-check that the updated CSS got copied over into littlebutton-react/src/button.css. If not, you can run yarn syncStyles. Note that if you forget to run yarn syncStyles our dev script will do this for us when we next start the application anyway:
"dev": "yarn syncStyles && vite",
For our React implementation, we additionally need to add a composed CSS Modules class in littlebutton-react/src/button.module.css that is composed from the new .btn-primary:
.btnPrimary {
composes: btn-primary from './button.css';
}
Now we can update the markup in littlebutton-vue/src/App.vue to use the new mode prop:
<Button mode="primary">Go</Button>
Now you can yarn start:vue from the top-level directory and check for the same green button.
Svelte
Let’s cd into littlebutton-svelte and verify that the styles in littlebutton-svelte/src/Button.svelte have the new .btn-primary class copied over, and yarn syncStyles if you need to. Again, the dev script will do that for us anyway on the next startup if you happen to forget.
Next, update the Svelte template to pass the mode of primary. In src/App.svelte:
<script>
import Button from './Button.svelte';
</script>
<main>
<Button mode="primary">Go</Button>
</main>
We also need to update the top of our src/Button.svelte component itself to accept the mode prop and apply the CSS Modules class:
Now we need to set up a binding to a classes getter to compute the correct classes based on if the mode was passed in to the component or not. Add this to littlebutton-angular/src/components/button.component.html (and note the binding is happening with the square brackets):
<button [class]="classes">Go</button>
Next, we actually need to create the classes binding in our component at littlebutton-angular/src/components/button.component.ts:
We use the Input directive to take in the mode prop, then we create a classes accessor which adds the mode class if it’s been passed in.
Fire it up and look for the green button!
Code complete
If you’ve made it this far, congratulations — you’ve reached code complete! If something went awry, I’d encourage you to cross-reference the source code over at GitHub on the the-little-button-that-could-series branch. As bundlers and packages have a tendency to change abruptly, you might want to pin your package versions to the ones in this branch if you happen to experience any dependency issues.
Take a moment to go back and compare the four framework-based button component implementations we just built. They’re still small enough to quickly notice some interesting differences in how props get passed in, how we bind to props, and how CSS name collisions are prevented among other subtle differences. As I continue to add components to AgnosticUI (which supports these exact same four frameworks), I’m continually pondering which offers the best developer experience. What do you think?
Homework
If you’re the type that likes to figure things out on your own or enjoys digging in deeper, here are ideas.
Button states
The current button styles do not account for various states, like :hover. I believe that’s a good first exercise.
/* You should really implement the following states
but I will leave it as an exercise for you to
decide how to and what values to use.
*/
.btn:focus {
/* If you elect to remove the outline, replace it
with another proper affordance and research how
to use transparent outlines to support windows
high contrast
*/
}
.btn:hover { }
.btn:visited { }
.btn:active { }
.btn:disabled { }
Variants
Most button libraries support many button variations for things like sizes, shapes, and colors. Try creating more than the primary mode we already have. Maybe a secondary variation? A warning or success? Maybe filled and outline? Again, you can look at AgnosticUI’s buttons page for ideas.
CSS custom properties
If you haven’t started using CSS custom properties yet, I’d strongly recommend it. You can start by having a look at AgnosticUI’s common styles. I heavily lean on custom properties in there. Here are some great articles that cover what custom properties are and how you might leverage them:
No… not typings, but the <button> element’s type attribute. We didn’t cover that in our component but there’s an opportunity to extend the component to other use cases with valid types, like button, submit, and reset. This is pretty easy to do and will greatly improve the button’s API.
More ideas
Gosh, you could do so much — add linting, convert it to Typescript, audit the accessibility, etc.
The current Svelte implementation is suffering from some pretty loose assumptions as we have no defense if the valid primary mode isn’t passed — that would produce a garbage CSS class:
mode ? `btn-${mode}` : "",
You could say, “Well, .btn-garbage as a class isn’t exactly harmful.” But it’s probably a good idea to style defensively when and where possible.
Potential pitfalls
There are some things you should be aware of before taking this approach further:
Positional CSS based on the structure of the markup will not work well for the CSS Modules based techniques used here.
Angular makes positional techniques even harder as it generates :host element representing each component view. This means you have these extra elements in between your template or markup structure. You’ll need to work around that.
Copying styles across workspace packages is a bit of an anti-pattern to some folks. I justify it because I believe the benefits outweigh the costs; also, when I think about how monorepos use symlinks and (not-so-failproof) hoisting, I don’t feel so bad about this approach.
You’ll have to subscribe to the decoupled techniques used here, so no CSS-in-JS.
I believe that all approaches to software development have their pros and cons and you ultimately have to decide if sharing a single CSS file across frameworks works for you or your specific project. There are certainly other ways you could do this (e.g. using littlebuttons-css as an npm package dependency) if needed.
Conclusion
Hopefully I’ve whet your appetite and you’re now really intrigued to create UI component libraries and/or design systems that are not tied to a particular framework. Maybe you have a better idea on how to achieve this — I’d love to hear your thoughts in the comments!
I’m sure you’ve seen the venerable TodoMVC project and how many framework implementations have been created for it. Similarly, wouldn’t it be nice to have a UI component library of primitives available for many frameworks? Open UI is making great strides to properly standardize native UI component defaults, but I believe we’ll always need to insert ourselves to some extent. Certainly, taking a good year to build a custom design system is quickly falling out of favor and companies are seriously questioning their ROI. Some sort of scaffolding is required to make the endeavor practical.
The vision of AgnosticUI is to have a relatively agnostic way to build design systems quickly that are not tied down to a particular frontend framework. If you’re compelled to get involved, the project is still very early and approachable and I’d love some help! Plus, you’re already pretty familiar with the how the project works now that you’ve gone through this tutorial!
CSS overrides can change the default look of almost anything:
You can use CSS to override what a checkbox or radio button looks like, but if you don’t, the checkbox will look like a default checkbox on your operating system and some would say that’s best for accessibility and usability.
You can use CSS to override what a select menu looks like, but if you don’t, the select will look like a default select menu on your operating system and some would say that’s best for accessibility and usability.
You can override what anchor links look like, but some would say they should be blue with underlines because that is the default and it’s best for accessibility and usability.
You can override what scrollbars look like, but if you don’t, the scrollbars will look (and behave) the way default scrollbars do on your operating system, and some would say that’s best for accessibility and usability.
In my experience, everyone has a different line. Nearly everybody styles their buttons. Nearly everybody styles their links, but some might only customize the hue of blue and leave the underline, drawing the line at more elaborate changes. It’s fairly popular to style form elements like checkboxes, radio buttons, and selects, but some people draw the line before that.
Some people draw a line saying you should never change a default cursor, some push that line back to make the cursor into a pointer for created interactive elements, some push that line so far they are OK with custom images as cursors. Some people draw the line with scrollbars saying they should never be customized, while some people implement elaborate designs.
CSS is a language for changing the design of websites. Every ruleset you write likely changes the defaults of something. The lines are relatively fuzzy, but I’d say there is nothing in CSS that should be outright banned from use — it’s more about the styling choices you make. So when you do choose to style something, it remains usable and accessible. Heck, background-color can be terribly abused making for inaccessible and unusable areas of a site, but nobody raises pitchforks over that.
