Switch font color for different backgrounds with CSS

Ever get one of those, "I can do that with CSS!" moments while watching someone flex their JavaScript muscles? That’s exactly the feeling I got while watching Dag-Inge Aas & Ida Aalen talk at CSSconf EU 2018.

They are based in Norway, where WCAG accessibility is not a just good practice, but actually required by law (go, Norway!). As they were developing a feature that allows user-selectable color theming for their main product, they faced a challenge: automatically adjusting the font color based on the selected background color of the container. If the background is dark, then it would be ideal to have a white text to keep it WCAG contrast compliant. But what happens if a light background color is selected instead? The text is both illegible and fails accessibility.

They used an elegant approach and solved the issue using the "color" npm package, adding conditional borders and automatic secondary color generation while they were at it.

But that’s a JavaScript solution. Here’s my pure CSS alternative.


Why would you do that in CSS?

Have you seen Lynn Fisher's extraordinary A Single Div project? Not only are all these graphics drawn in just HTML and CSS, they are all created with (you guessed it) a single <div>.

Why would she do that? Here's one pertinent possibility: it's none of our business. We're free to wonder, or even ask if it's done respectfully enough. But does it really matter? Let's stop short of assuming she doesn't know what's she's doing, assuming it's a twisted form of pain, or that she's unaware of other technologies. Check out the example where she drew the official SVG logo with CSS and a single div. Woke.

Scooped Corners in 2018

When I saw Chris' article on notched boxes, I remembered that I got a challenge a while ago to CSS a design like it, but with rounded, scooped corners instead. So, let's see how we can do it that way instead and expand it to multiple corners while being mindful of browser support.

CSS Basics: The Second “S” in CSS

CSS is an abbreviation for Cascading Style Sheets.

While most of the discussion about CSS on the web (or even here on CSS-Tricks) is centered around writing styles and how the cascade affects them, what we don't talk a whole lot about is the sheet part of the language. So let's give that lonely second "S" a little bit of the spotlight and understand what we mean when we say CSS is a style sheet.


A Sliding Nightmare: Understanding the Range Input

You may have already seen a bunch of tutorials on how to style the range input. While this is another article on that topic, it's not about how to get any specific visual result. Instead, it dives into browser inconsistencies, detailing what each does to display that slider on the screen. Understanding this is important because it helps us have a clear idea about whether we can make our slider look and behave consistently across browsers and which styles are necessary to do so.


The Best Way to Implement a “Wrapper” in CSS

Sometimes the first bit of HTML we write in a new document is an element that wraps everything else on the page. The term wrapper is common for that. We give it a class, and that class is responsible for encapsulating all visual elements on the page.

I've always struggled to with the best way to implement it. I found a related thread on StackOverflow that has more than 250,000 views, so obviously I'm not the only one wondering! I'll sum up my latest thoughts in this article.


The Options for Programmatically Documenting CSS

I strongly believe that the documentation should be kept as close to the code as possible. Based on my experience, that's the only option that works well in the long term. External documents, notes, and wikis all eventually get outdated, forgotten, and lost.

Documentation is a topic that always bugs me. Working on poorly documented codebase is a ticking bomb. It makes the onboarding process a tedious experience. Another way to think of bad documentation is that it helps foster a low truck factor (that is, "the number of people on your team who have to be hit by a truck before the project is in serious trouble").

Recently I was on-boarded into a project with more than 1,500 pages of documentation written in… Microsoft Word. It was outdated and unorganized. A real disaster. There must be a better way!

I've talked about this documentation issue before. I scratched the surface not long ago here on CSS-Tricks in my article What Does a Well-Documented CSS Codebase Look Like? Now, let's drill down into the options for programmatically documenting code. Specifically CSS.


What Does a Well-Documented CSS Codebase Look Like?

In the front-end community, there is a lot of attention related to documenting JavaScript. That's not so much the case with CSS. Often times I feel like lost when I join a project with minimal or no CSS documentation.

Even though CSS is relatively easy to write, it can be quite hard to maintain. The specificity, the global scope of everything, and the lack of guidance can easily lead to inconsistency, code duplication, and over-complication.

I've long been curious what a really well-documented CSS codebase looks like. Here, I'll share my experience, along with the expectations I have towards my vision of well-documented stylesheets.


`font-display` for the Masses

Updated on January 12, 2017: Proper support checks are now part of the article body. Added information about the block value. Minor tweaks and copy edits. Enjoy!

If you're a regular reader here at CSS-Tricks, chances are good you know a bit about web fonts. You may even know a few useful tricks to control how fonts load, but have you used the CSS font-display property?

The font-display property in CSS is available in Chrome, and emerging in Firefox and Safari (but you might want to check browser support for yourself, since things change all the time). It's a simpler way of achieving what the Font Loading API is capable of, as well as third party scripts such as Bram Stein's Font Face Observer.