Day: April 15, 2024

I like Melanie Sumner’s coining of the phrase Continuous Accessibility. To me, it’s like a play on the term Continuous Integration (CI) that is very pervasive. We build CI pipelines to lint our code, test our code, and test our code primarily, but all sorts of things can be done. We can test new code for performance regressions for example. So too could and should we be testing our new code for accessibility issues. Continuously, as it were. I’m very guilty of failing at the continuous part. I care about and act on accessibility issues, but I tend to do it in waves or sprints rather than all the time.

I like the career value that Ben Nadel assigns to learning RegEx. He says not a day goes by he doesn’t use them in some form (!). I wouldn’t say that’s true for me, but certainly every week or two I need to think about them, and over the years, my fear-factor in using them has scaled down to zero. They really aren’t that bad, it’s just a long steady learning curve to the point where eventually you feel like even if I’m slow I can ultimately reason this out. Either figuring out an existing one or writing a new one. Ben doesn’t just talk about it abstractly, he lists loads of practical examples.

Before I move on, allow me to show you Hillel Wayne agreeing with Regexes are Cool and Good (that’s my kind of title). Hillel mentions some valid reasons why people have a distaste for them, but then brings up a super good point: RegExes are particularly good when you’ve got some muscle memory for them and use them in little one-off use cases.

… where regex really shines is in interactive use. When you’re trying to substitute in a single file you have open, or grep a folder, things like that. Readability doesn’t matter because you’re writing a one-off throwaway, and fragility is fine because you’re a human-in-the-loop. If anything goes wrong you will see that and tweak the regex.

Heck yeah. If you get good at it, using them for Find/Replace reasons in your code editor can make you look like damn superhero.

Oh and thank heavens for RegEx101 and sites like it. So good.

I really like the CSS only “scroll-to-top” trick that David Darnes created and Stefan Judis wrote up. It’s just so deliciously clever. A scroll-to-top link is just a UX convenience and accessibility feature, as it not only scrolls to the top but moves focus back up there as well. It’s like…

<a href="#top" class="back-to-top-link">Back to Top</a>

But where and when do you show it? It could just be down in the footer of a site. But a classy way to do it is to show it on long-scrolling pages pretty much all the time — just not when the page is already scrolled to the top. Say you want to wait until the user has scrolled down at least 200px or something like that. Feels like JavaScript territory, but no, that’s where David’s trick shines: this can all be done in CSS.

The bare-bones part of the trick:

.back-to-top-link {
  margin-block-start: calc(100vh + 200px);
  position: sticky;
  bottom: 1rem;
  left: 1rem;
}

Here’s a demo.

I like the relative color syntax. Support for it is coming along and it’s in Interop 2024 so “actually using it” isn’t terribly far away. What I like is that it allows you to manipulate a color on the fly in a way that will actually work well without needing anything other than native CSS.

Thought process:

• I’ve got this orange color
• I wish I had a version of it that was a bit darker
• … and is a bit alpha transparent.

So I’ve got the color:

body {
  --color: #f06d06;
}

Then I can use it, and I can use my modified version easily.

.box {
  background: var(--color);
  border: 20px solid oklch(from var(--color) calc(l - 0.5) c h / 0.5);
}

I’m using OKLCH there because it has “perceptually uniform lightness” so if I manipulate all my colors the same amount, they will feel the same amount manipulated. I don’t have to use that function, I could use rgb() or hsl() or even the generic color(). That’s the thing with the relative color syntax, it’s not any particular function, it’s largely that from keyword.

I like the idea of things challenging the dominance of npm. Much like Deno is challenging Node, and is literally from the same creator, now vlt is challenging npm and is from the same creator. Well, he’s on the team anyway. I remember listening to Darcy Clarke on Syntax saying some smart stuff about this new package manager possibility. Like, I’m the user, right? It’s my computer, and I’m asking this tool to go get a package for me. Why can’t I say “don’t get the README though, I don’t need it, and definitely skip the 1.5 MB JPG in that README, I just need the JavaScript file.” Makes a lot of sense to me. Give me a pre-built version! Don’t give me the types, I’m not using TypeScript. That kind of thing. I’m sure that like 1% of what this thing will be able to do, I just like the fresh thinking. I’m sure it’s more about the security. We’ve got JSR in there shaking stuff up now too, which I like because it isn’t friggin lowecase.