When you’re wireframing though, you’re almost pre-design prototype at that phase. You might still be in Figma or the like though, so what font do you choose then? I love the idea of using a font that just references the idea of type being there, but isn’t actual letterforms. That way you still get the sizing and reflowing and everything of real type, without worrying at all about the actual text. I had trouble finding something (I kept looking for “squiggle fonts” and not finding anything.) So now that I have found them, I’m linking them up:

• Redacted Script on Google Fonts by Christian Naths
• Flow Block on Google Fonts by Dan Ross
• FILLR on PowerMockup by Andreas
• BLOKK on GitHub by Los Gordos

I used Redacted for the graphic I made for this post.

.element {
  filter: blur(2px) grayscale(80%) contrast(200%);
}

All three of those filters will apply. But somehow I never thought about applying the same filter more than once. That also works, and they don’t override each other, they “stack” (or whatever you want to call it).

So here’s some useless bar trivia for you. What is blurrier, filter: blur(2px) or filter: blur(1px) blur(1px)? Answer.

… we want you to be able to use this CSS to make your text easier to read and softer on the eyes, to provide your users with better readability and accessibility. And simply, to make something beautiful.

If you’ve got Safari Technical Preview going, try the demo. I’ve seen one small bit of valid criticism.

.stroke-text {
  -webkit-text-stroke: 5px red;
}

Despite the vendor prefix there, it works across all browsers.

But I’ve never liked it… until recently.

I’m not sure if I’ve ever spelled out exactly why, so first let me do that. Here’s a nice R from Roslindale.

Which is made up of vector points like all fonts:

In an application like Adobe Illustrator which gives me control over how a vector shape applies a stroke, if I stroke the outside it ends up looking OK as the integrity of the letterform is preserved.

It’s a bit harder to do with Roslindale “R” with the narrow passages at the top and middle of the letterform here, but we can apply stroke to the inside as well and the overall shape of the letter stays the same.

But if we apply a stroke to the “middle”, that is, straddled across the edge of the shape such that the stroke is equal on both sides, now we’ve ruined the shape of the letter and it looks like 💩.

This is even more pronounced as we deal with more text.

Point is: center aligned stroke sucks. And guess what the only option is for -webkit-text-stroke? Center-aligned. And, equally sadly, all strokes in SVG, a bonkers omission for a vector painting specific language.

Alas there is a half decent and kinda fun workaround. The trick is essentially using paint-order (which works in CSS and SVG) to make sure that the “fill” of the element is drawn on top of the “stroke”, which effectively makes the stroke appear as if it’s outside-aligned even if it’s not actually doing that.

.stroke-text {
  paint-order: stroke fill; /* fill is on top */
  -webkit-text-stroke: 5px red;
}

With this combo we can make stroked text tolerable:

Just putting that fill on top can fix some different awkward situations. Here’s Adam Argyle showing how a text-shadow can really interfere, and then fixing it by forcing that fill layer back on top again.

Wes Bos showed this off, layering on some text-shadow stuff as well, which resulted in a great look:

I had a play as well, and I really like the combination of being able to use a text stroke safely and being able to use a text shadow for an additional effect. Here the shadow comes up on top of the text giving it an actual embossed look:

You could have a play with this one, adding more text shadows or adjusting colors or whatever to get a nice look.

Perhaps goes without saying but I’ll say it anyway: thicker typefaces are going to generally work better with this.

Here’s how links look with entirely default styles:

Me, I think that look is a bit intense. I think it can be improved by keeping the spirit of what is going on there but chilling it out a bit.

Nudge the Underline Away

I think the characters are a bit more legible if we move that underline away a little. Let’s make the font system-ui and kick that underline away a smidge:

a {
  text-underline-offset: 2px;
}

I think that’s broadly better, regardless of font-family, line-height, etc.

Add Opacity to the Underline

This is the part that chills the link style out the most, while still reading strongly as a link. We’ve got text-decoration-color to use for this, which we can just apply a chilled out color directly. But we can be a bit smarter!

• Rather than setting a 2nd static color, let’s leverage the currentColor. That way it’s not yet-another-color we have to manage.
• Let’s use this alteration for our :hover and :focus styles, which can be another hard choice!

The relative color syntax would be cool here, but full cross-browser support is a smidge away on that yet, so let’s use the better-supported color-mix() instead.

For a smidge of extra trickery we’ll only apply the opacity underline when the link is “not” hovered or focused, meaning when it is that will be removed:

a:not(:is(:hover, :focus)) {
  text-decoration-color: 
    color-mix(in srgb, currentColor, transparent 75%);
}

Color Away!

By using currentColor it means that whatever color the links are, we get this chilled out style that comes along for the ride no matter what.

Possibly a decent candidate for a default stylesheet.

Is all this accessible? My guess is that as long as the color of the link has enough contrast against the background, and the keyboard focus styles are strong, it’s fine. But if I’m wrong feel free to correct me here.

Demo

Need an arrow that points up and to the left, that also has a circle around it? I actually assumed there wasn’t one, but there totally is.

Here’s what has me thinking about all that.

We’ve got a monorepo at work.

We’ve been moving to TypeScript for years, with mostly positive results. I’m fairly convinced that the code output from writing in TypeScript is better and the experience of writing and editing existing TypeScript code is better DX.

It’s not without challenges though. I hate wasting time futzing with types when I just know it really isn’t improving the quality of my code I’m just fighting with a machine. This concern is multiplied when you see your team doing the same thing.

Another challenge is the part where you actually have to produce JavaScript. This is not a difficult job in and of itself. There are loads of tools that do this from the canonical tsc to tools that do no type checking but can very speedily compile TS to JS (like esbuild). But sometimes, you still have to do it.

One example from our monorepo is that we have some components that we’d like to write in .tsx, but they can be consumed by a number of different site building tools (e.g. a Next.js site, an Astro site, an classic Just Load React On The Page site, etc). The most sane way of handling this is processing the TS into JS ahead of time. That way whatever site that wants to import them can do it as native, normal JavaScript ESM stuff.

monorepo
  website-1
  website-2
  packages
    components
      dist
        MyVeryImportantComponent
          index.js
      src
        MyVeryImportantComponent
          index.tsx   

Now I need to make a build process to do this. I’ll probably write a little script. npm run process-packages or whatever, fine. I’ll probably use tsc for this on purpose, knowing that it isn’t the fastest, but it’s the one that is capable of actually throwing errors when there are TypeScript problems. This is useful because I can call my script in a pre-commit hook in Git, for example, to prevent myself and my team from committing bad TypeScript. I can call the script in CI as well which is additional protection.

So now I have tsc building from src to dist, great. But TypeScript explicitly will never build an “other files” copy machine. Well that’s annoying. What about my other stuff?

packages
  components
    src
      MyVeryImportantComponent
        index.tsx
        queries.graphql
        styles.module.scss

Now I have to wire up some new machine to copy anything that isn’t TypeScript over from src to dist. Blech. Fine, I’ll do it.

But this is all complicated by the fact that this script we’re building needs to be able to run two ways:

1. As a builder, where you call it and it does the job
2. As a watcher, where it runs the build when any pertinent file changes

It’s unacceptable DX to expect a developer to run a build command after every file change manually. So we have to build our own little watcher too. I guess it’s Chokidar time? I hate piling on dependencies, but that’s the only watcher that’s ever felt truly reliable to me.

I don’t mean to paint this picture too negatively. This is all doable. This is the job. There are tools to help with this that get better over time. But wow, it’s a lot when you consider it was just TypeScript, this invisible layer of special code helping syntax, that pushed us this far into toolsville.

I’d rather focus on the positive stuff I’m seeing here. As the years tick by, and TypeScripts popularity remains high, the surrounding tools that deal in JavaScript are more and more fine with “just leave it as TypeScript.” I find that interesting!

This “native” support of TypeScript is a product choice. We know some of our customers write and prefer TypeScript so we’ll make it easier for them. But there is no Official™ way to do this. The product needs to decide how they are going to handle it. Are they going to check types for you and alert you (somehow? somewhere?) to type problems? Or are they leaving type problems to you, and if the code compiles to JavaScript, so it shall be. What version of TypeScript is it going to support? Is configuration necessary?

So what are these products?

Tools & Products That Let You Write TypeScript “Natively”

Frameworks

• Astro: “Astro ships with built-in support for TypeScript. You can import .ts and .tsx files in your Astro project, write TypeScript code directly inside your Astro component, and even use an astro.config.ts file for your Astro configuration if you like.”
• Next.js: “Next.js comes with built-in TypeScript, automatically installing the necessary packages and configuring the proper settings”
• This is pretty common in UI meta frameworks… Nuxt, Remix, SvelteKit, Redwood, etc. This, likely, is the thing that pushed other products to do the same.

Runtimes

• Deno: “TypeScript is a first class language in Deno, just like JavaScript or WebAssembly.” You can just deno run script.ts, deploy .ts files to their cloud service, and there is a type checking command. See what I mean about it being a product choice?
• Bun: “Bun treats TypeScript as a first-class citizen.”
• Cloudflare Workers: “TypeScript is a first-class language on Cloudflare Workers.”

Bundlers

• Vite: “Vite supports importing .ts files out of the box.”
• esbuild: “…esbuild has built-in support for parsing TypeScript syntax and discarding the type annotations.”
• Parcel: “Parcel supports TypeScript out of the box without any additional configuration.”

Meta

• tsx: The big thing here is the tsx project, or “TypeScript Execute”. A lot of times what you’re trying to do in Node is node script.ts, like in an npm script, but you can’t, because Node doesn’t support TypeScript “natively”. But replace node with tsx, and it works.

Drumroll?

I started writing this post a few weeks ago, and now I’ve just seen: Node.js Now Supports TypeScript By Default.

Node 23 will soon be able to run TypeScript files without any extra configuration.

You can run node index.ts with no further flags

Node will strip out the types using a version of swc, then run the resulting code.

Well there ya have it. Feels like we were on to something there eh?

I feel like this pushed it more into Official™ territory and now this will be less of a product-level choice and more of a “leverage what the technology already does” choice. For instance, products don’t have do anything special or build additional technology to support TypeScript, they’ll just do what Node does. And they won’t have to fret over “well should we do type checking?” because they can just follow in the steps of what the tool already does (just strip them).

𝐂𝐚𝐥𝐥𝐞 𝐁𝐥𝐚𝐧𝐜𝐨𝐬, 𝐂𝐨𝐬𝐭𝐚 𝐑𝐢𝐜𝐚

He said he could not remove that formatting no matter what he did. It looks kinda bold, doesn’t it? And set into a serif font. You’d think you could select it in the text editor you’re in and remove that formatting. He said he tried copy/pasting it into places where no text formatting is even allowed, like in VS Code or the URL bar of a browser. Voodoo, he said.

Here’s the thing: that text isn’t formatted.

That first “C” you see above isn’t a regular uppercase character C, our typical friend U+0043 : LATIN CAPITAL LETTER C, it’s “𝐂”, that is, U+1D402 : MATHEMATICAL BOLD CAPITAL C. It’s literally a different character in Unicode. There are… a lot of Unicode characters:

As of Unicode version 16.0, there are 155,063 characters with code points, covering 168 modern and historical scripts, as well as multiple symbol sets.

List of Unicode characters — Wikipedia

It could be written like 𝕮𝖆𝖑𝖑𝖊 𝕭𝖑𝖆𝖓𝖈𝖔𝖘, 𝕮𝖔𝖘𝖙𝖆 𝕽𝖎𝖈𝖆 instead, or 𝗖𝗮𝗹𝗹𝗲 𝗕𝗹𝗮𝗻𝗰𝗼𝘀, 𝗖𝗼𝘀𝘁𝗮 𝗥𝗶𝗰𝗮.

Should you do this to get super sweet effects in places you otherwise couldn’t? Probably not. The accessibility is rough. Listen to the audio output in this blog post. If you’re going to do it on the web where you have HTML control, do something like:

<!-- Don't do this! Leaving for posterity. -->
<span aria-label="Calle Blancos, Costa Rica">
  <span aria-hidden="true">𝕮𝖆𝖑𝖑𝖊 𝕭𝖑𝖆𝖓𝖈𝖔𝖘, 𝕮𝖔𝖘𝖙𝖆 𝕽𝖎𝖈𝖆</span>
</span>

UPDATE: See Ben’s comment on why not to do the above. Instead, make a visually hidden version that a screen reader would still see, and an ARIA hidden one that will be seen visually. (Noting potential concerns about copy/paste that started this whole article.)

<span class="visually-hidden">Calle Blancos, Costa Rica</span>
<span aria-hidden="true">𝕮𝖆𝖑𝖑𝖊 𝕭𝖑𝖆𝖓𝖈𝖔𝖘, 𝕮𝖔𝖘𝖙𝖆 𝕽𝖎𝖈𝖆</span>