Published by

Color contrast tools to check against APCA

EL introduced me to contrast.tools recently, it uses the Advanced Perception of Color Algorithm (APCA) to check the accessibility of your text based on the desired colors and the font weight + size. But importantly, it also provides a lookup table to verify how you should (possibly, probably) interpret things.

I think that APCA is being floated as the new contrast algorithm for WCAG 3.0? But I’d need to look in to it more to be sure. Apparently APCA Readability Criterion (ARC) might be a new standard for visual contrast.

Side note: I kind of wish we could get away from acronyms-within-acronyms-within-acronyms in the accessibility standards world…

Published by

CSS blend modes: beware the stacking context

I’m working on a site with a complex entanglement of blend modes, SVG backgrounds, gradient backgrounds, positioning, and transitions. I’ve run in to a bunch of issues with mix-blend-mode not working as expected, and it almost always has to do with an inappropriate stacking context.

For posterity, this StackOverflow answer is a really good run-down of CSS combos that create new stacking contexts.

Now to see what I can do about browsers rendering color profiles slightly differently… 💀

Edit: UGHHHHHH it’s different in different browsers. Check out this CodePen in Chrome and Firefox vs Safari. This is why we can’t have nice things.

Edit 2: See the answer to the cross-browser problem from the previous CodePen, via Gregory Cadars (view thread). So Safari is actually behaving correctly, but it’s still a stacking context issue.

To recap: I’m trying to display a “fixed” gradient background with content that scrolls over the top of it. Within this content, only the images have mix-blend-mode: overlay. In the original CodePen, I’m achieving this via a fixed position, 100% width + 100% height element with a linear gradient. This is within the same wrapper as the content.

My example is working in Chrome and Firefox. In Safari, it is effectively as if the blend mode hasn’t been applied. Though I’m not sure why the difference between browsers, it does make sense that a fixed position element would still create a new stacking context regardless of its parent.

In Gregory’s example, he’s removed the fixed position element with the gradient and instead applied the gradient background to the wrapper, as well as background-attachment: fixed via the background shorthand. This achieves the exact same effect, without stacking context issues.

The only thing that gives me pause is performance… I remember running in to some issues when I considered using background-attachment: fixed for Elizabeth Peyton’s Eternal Return. I can’t remember what it was exactly but it had to do with repainting on every scroll event (so, a lot!). I think that this article may give some context, but I’ll have to dig in to it further.

Related: See this CSS gradients resampling tool by Rutherford Craze for smoother gradients, shared by Gregory in the thread.

Twitter is a crappy place a lot of the time, but I love it for things like this.

Published by

A web color space that respects *real* lightness

Lea Verou just published a blog post about the LCH color space. This is super exciting, see her post for detail. Specifically, the improvement has to do with the perceptual uniformity and lightness being visually consistent no matter the hue.

The best way to get a feel for this is to experiment with her LCH color picker. Drag the hue value back and forth, and you’ll see that the tonality of the background remains consistent. It doesn’t suddenly feel a lot lighter in yellow than it does in blue. Do the same thing in an HSL color picker and you’ll feel the difference.

This would help a lot with the color on my site. I’ve never been 100% happy with how the color is handled because it is too hard to control the lightness and thus the legibility. See the List page for a clear example of this, posts in June and February are particularly hard to read. LCH would solve this!

Published by

Date-based colour

Read “Dynamic, Date-Based Color with JavaScript, HSL, and CSS Variables” by Rob Weychert

This is such a useful article. His implementation on Tinnitus Tracker is definitely more involved than what I’ve done on this site, particularly what he’s done to account for inherent saturation levels and lightness vs luminance. And his colour wheel mapping is slightly offset from mine. I feel like August is the reddest month! I’ve wanted to reconsider the colour here for a while, particularly since the accessibility of some of the hues isn’t up-to-snuff. Rob’s write-up might make that adjustment a bit more straightforward which is a big relief.

I remember being really interested in where Grant Custer went with colour on his blog when I started screwing around with colour on this site. See his blog in 2013 on the Internet Archive. I wanted to see whether or not there was some way to ambiguously reflect where I was in the world, particularly since I live so far away from most of my family.

The first version of the colour experimentation on this site mapped the HSL values to the season, temperature, and time of day where I was at the time the site was visited. This is an example from Paris in late 2016. The hue value was mapped to the date/season (same as now), and the lightness was mapped to the time of day using Moment.js and Moment Timezone. The goal was to map the saturation to the weather where I was using the OpenWeatherMap API with stormy and cloudy days being less saturated, but that never came to be since the weather descriptions weren’t consistent enough. I ended up mapping the saturation to the temperature instead, but I don’t think it was quite as effective.

When I turned the site in to a blog first and foremost, I dropped the location and weather aspect. It could be fun to return to it since it might bring a bit more variation, particularly on the list page. Might be a little wild though, and it might be a massive headache to introduce location and weather on old posts… At bare minimum, I could probably incorporate the time of day as lightness. We’ll see!