#242: The Absolute Joy of hsl()

[Robin]: hsl() is my new favorite design tool. Okay, so it’s not entirely new — hsl() has been around for a while — but I’ve caught myself using this new color format lately and, from now on, I’ll be avoiding writing CSS like this:

.element {
  color: #b91313;
}

And instead I’m going to start writing something like this instead:

.element {
  color: hsla(0, 81%, 40%, 1);
}

Why’s that? Well, the nifty thing about hsl() is that once you get used to the syntax it’s relatively easy to read and understand which values do what. While we’re at it, here’s a more modern syntax for it (note the lack of commas, and using the forward slash for alpha if you need it):

.element {
  background: hsl(0 81% 40%);
  background: hsl(0 81% 40% / 1);
}

This color format makes it straightforward to manipulate colors logically and programmatically: Let’s break down what hsl() means:

  • Hue: that’s your red/blue/yellow/green etc.
  • Saturation: the gray-ness of that color (so gray-ish red, or red-ish red).
  • Lightness: the brightness of that color.
  • Alpha: the opacity.

This means that when you want to pick a new color you don’t have to use the color picker at all, you can tweak these values in your text editor and understand what each of these numbers are. It’s pretty neat.

The other day I used it to compare two colors in a visual diff UI and make sure that they look good together. All I had to do was change the hue of these colors and it worked immediately. Didn’t have to open up a design tool, or fiddle around with a bunch of options.

I love that the color picker now includes color accessibility right here as I’m editing things so I don’t need to go to an external website or tool. See there how the contrast ratio is 2.08? That’s not good enough for accessibility and so I should think about changing the color right away.

But clicking through each of the different color formats is also incredibly handy because it means I don’t need another tool to convert them either. I can see a hex value, quickly switch to hsl, and then change the value to immediately get a better color than the one I had before.

Bonus tip: you can use CSS custom properties to just charge parts of an hsl() value.


Firebase Crash Course

I loved this piece by David East about Firebase: what it is, how it works, and why us front-end folk should care about it. The example is pretty darn exciting as David shows us how to set up a database and then use that data in CSS with a conic gradient to create a graph, like this:

I think this is very exciting stuff as it sort of underlines what Chris has been saying for some time now: our relationship with back-end technology is blurry and also is constantly changing. And tools like Firebase give us super powers.


Too Many SVGs Clogging Up Your Markup? Try use

When it comes to SVG, <use> is your best friend. Georgi Nikoloff explains how he made optimized this series of charts:

This works and renders just fine, but results in a bloated DOM tree, where each shape is represented as separate nodes. Displaying all 50 graphs simultaneously on a web page results in 5,951 DOM elements in total, which is far too many.

This many DOM nodes is bad for performance and SEO, but the solution here is thankfully not too complex. We can reach for the use tag that lets us reuse parts of an SVG once and then refer to it over and over again.

All the way back in 2014, Chris wrote about how he used (pun intended, sorry) the use tag to create an SVG icon system. You can use (ugh, sorry I cannot stop) them like this anywhere in your HTML:

<svg viewBox="0 0 100 100" class="icon shape-codepen">
  <use xlink:href="#shape-codepen"></use>
</svg>

That tag can then go fetch that #shape-codepen ID from another SVG that could live at the top of your HTML, like this:

<svg>
  <defs>
    <g id="shape-codepen">
      <!-- all the paths and shapes and whatnot for this icon -->
    <g>
    <g id="shape-github">
      <!-- all the paths and shapes and whatnot for this icon -->
    <g>
    <!-- etc -->
  </defs>
</svg>

No need to declare it over and over again or have a million DOM nodes in the tree. Pretty nifty.


Web Components Are Easier Than You Think

In this post, John Rhea argues that web components aren’t scary:

[…] in a recent reference project to make learning HTML easier (by adding zombies and silly jokes, of course), the completist in me decided I had to cover every HTML element in the spec. Beyond those conference presentations, this was my first introduction to the <slot> and <template> elements. But as I tried to write something accurate and engaging, I was forced to delve a bit deeper.

And I’ve learned something in the process: web components are a lot easier than I remember.

John shows how this all ties together by creating a reusable web component for a zombie dating service where each element inside can be quickly recreated over and over again by using that element:


A History of Web Standards

I’ve been a big fan of Jay Hoffman’s ongoing series about how the web was created and his latest post about web standards is great, too. What are web standards? They’re effectively a handshake agreement between browser manufacturers about how the web should work. For example, if the Chrome team just shipped an HTML element that didn’t work elsewhere or had major accessibility concerns then that could hurt the open web. (Oh wait, that sounds kinda familiar.) Stuff would stop working across browsers, developers and users could get confused, and we could go back to where we were in the 90s where the web fractured into smaller pieces.

Without web standards, it would become exponentially more difficult for us to build websites today. We’d return to a new dark age where banners would adorn the top of websites with something like “Best viewed in Safari.” (Well, we still see these today but they’re not as common as they once were.)

A lack of web standards would lead to an unhealthy web. As Jay writes:

When done properly, standards set a technical lodestar. Companies with competing interests and priorities can orient themselves around a common set of agreed upon documentation about how a technology should work. Consensus on shared standards creates interoperability; competition happens through user experience instead of technical infrastructure.

Reading about this history reminds me to be grateful for all the time and energy that’s been spent making sure that these words I type to you now can render correctly and be understood, regardless of whatever browser you might be using.


Sendbird

Save time building in-app chat, voice and video for mobile, and web applications with Sendbird! Get to market faster with Sendbird’s UIKit, pre-built UI components, best-in-class documentation and support for developers.


Stay current with today’s best web design practices

An Event Apart Online Together: Spring Summit features fifteen important sessions from world-class experts to keep you up-to-date with today’s best practices. Join us online April 19–21. You can even catch Chris and Dave hoping a live episode of ShopTalk!

Don’t miss the opportunity to take your career to the next level. Check out the detailed Spring Summit three-day schedule and register today.


[Chris]: I heard about a new typeface, Codelia by Toshi Omagari, through Robin’s newsletter. Looks like it could be mighty nice for coding, but I think it’s just nice-lookin’ all around.

It’s only available to buy on-demand from MyFonts. If I wanted to use it here on CSS-Tricks, that’s based on a pageviews metric, so I plugged in our last 30 days of pageviews and got:

Cost of font is $14,258.78

A little outside our budget for a single font. I noticed the same thing for the recent release of ProximaVara. It’s terribly beautiful but also terribly expensive for a high-pageviews site:

Cost of font at $1,485.00

It does make some sort of sense that there is a sliding scale for font pricing. Particularly if where you are buying it is also footing the bill for hosting it (rarely the case, though). If some global brand wants to use a typeface a global billboard campaign, it feels like charging them more than one person wanting to use it in their personal code editor is fair. Yet, assessing that is tricky. You can’t exactly do a phone interview before each font sale. You can’t ask for tax returns. So apparently page views is the chosen metric when it comes to font usage on the web. And the problem is that page views and a sites financial success aren’t particularly well correlated. CSS-Tricks makes money, but not the kind of money that makes 7-figure fonts possible.

I’m not sure the honor system is a better way to go (although if you’re self-hosting the fonts anyway, it kinda is), but I just ran across an example of that which seemed kinda cool.

Ultralight is an “HTML renderer”, in the vein of Electron. So you get to make a native app, but use web tech to do it. They have paid licenses, but it looks largely like an honor system thing with a sliding scale based on the annual revenue of the company using it.

Maybe for fonts there should be a dropdown that affects the price like:

The site I’m going to use this font on…

  • Makes a boatload of money
  • Makes nominal money used for a part-time staff or lone owner
  • Actually costs me money

I can’t see it actually happening, but hey, it’s fun to think about.