Multi-stroke text effect in CSS

This is made with (and by the author of) <css-doodle>, a web component that lets you put the CSS variant used in this blog inline into your HTML, like so:

    <script src="https://esm.sh/css-doodle/css-doodle.min.js?raw"></script>
    <css-doodle>
      @grid: 15 / 90%;
      border-radius: 50%;
      background: hsl(@t(/20), 70%, 60%);
      scale: sin(@atan2(@dx, @dy) + @ts);
    </css-doodle>

No JS needed except for loading the definition of the <css-doodle> component. Works in plain HTML, Markdown, frameworks, etc.

https://css-doodle.com/

I wonder why the firefox CSS rendering engine prefers to smooth out. Looks like a dramatically different implementation, but maybe that's just because it's an edge case of rendering

OT: really love the design of this blog. Simple, clear and content first.

I just found out about https://css-doodle.com after reading that. A few months back, I was doing similar things with the HTML Canvas API. I didn’t know I could do these kinds of fun little things with CSS as well. Love that.

When I modified your fiddle to use the Apple logo and colors, the first ring is eating part of the apple. The top of the apple is cut off. Any idea why that is?

      --c: #5EBD3E,#FFB900,#F78200,#E23838,#973999,#009CDF;
      @content: '';

I wonder what is the best way to do double stroked text without using fancy Unicode characters while still displaying what the font recommends. I currently use fancy characters on [my blog](https://blog.velocifyer.com/), but that harms search results. I am in the processes of migrating my blog to 11ty (from manual HTML) and I want to improve my blog at the same time.

PS: Please give me comments on the current design of the blog.

Neat! It's unfortunate that the rendering is so different between browsers.

Have you tried the same thing with shadows? They can also be stacked, I believe.

First thing I thought to do was add an emoji to the content. But it just shows the unknown char rectangle. I was hoping for magic, I guess.

Eat your heart out Adobe Flash.

This is so freaking cool

People should quit trying to make CSS a drawing tool--it is not--and start learning how to use SVG instead or images.

This is so freaking cool

When I modified your fiddle to use the Apple logo and colors, the first ring is eating part of the apple. The top of the apple is cut off. Any idea why that is?

      --c: #5EBD3E,#FFB900,#F78200,#E23838,#973999,#009CDF;
      @content: '';

PS: Please give me comments on the current design of the blog.

Eat your heart out Adobe Flash.

This is made with (and by the author of) <css-doodle>, a web component that lets you put the CSS variant used in this blog inline into your HTML, like so:

    <script src="https://esm.sh/css-doodle/css-doodle.min.js?raw"></script>
    <css-doodle>
      @grid: 15 / 90%;
      border-radius: 50%;
      background: hsl(@t(/20), 70%, 60%);
      scale: sin(@atan2(@dx, @dy) + @ts);
    </css-doodle>

No JS needed except for loading the definition of the <css-doodle> component. Works in plain HTML, Markdown, frameworks, etc.

https://css-doodle.com/

Thanks for the explanation. I’ve moved away from frontend work in 2018, and I really have no idea what CSS can do anymore! So much of the CSS in this page looks cryptic to me.

Kudos to the author for posting something cool and new in the age of standardised styles.

I wonder why the firefox CSS rendering engine prefers to smooth out. Looks like a dramatically different implementation, but maybe that's just because it's an edge case of rendering

Stroke expansion is a complex topic, with more than one reasonable result (subjective preferences), and a whole lot of corner cases and incorrect answers.

Firefox has chosen to expand based on distance at all points, which is one of the reasonable answers and probably the most general one; a cusp then expands to a curve.

The others have chosen to retain cusps, which can be a reasonable answer and I believe is a lot cheaper to compute; but degenerate cases abound as you expand past the feature size (distances between nodes), so that by the fourth red ring it’s obviously incorrect.

Box shadows are another case where expansion occurs: the fourth length parameter, spread distance. If the corner is a cusp, the shadow corner will be a cusp. If it’s rounded, the shadow corner will be rounded. See https://drafts.csswg.org/css-backgrounds/#shadow-shape for some helpful diagrams. A sneaky trick: .1px border-radius means the box still looks square, but the expanded shadow will curve. Sometimes useful. But back on the original content of the article—if you use a font with microscopic curves instead of cusp nodes, Chromium/Safari will look more like Firefox.

While I don't entirely love the rounding effect of firefox, I feel Chrome interpretation is just wrong in creating spurious spikes. Intuitively for the asterisk shape I'd expect the outline to go towards a plain hexagon, something that neither browser accomplishes.

Miter join (Safari) VS round join (Chrome)

firefox looks like an SDF (shortest distance to the object), I'm not sure what the chrome one is...

The Firefox one looks like exactly what you’d expect from stepping the result of a SDF for that character. The rounded corners of the first layer would all be equidistant from the nearest corner of the original character.

I think Firefox applies more aggressive subpixel rendering and path smoothing before stroking. It resamples the glyph outline path at a higher precision level before handing it to the stroke algorithm.

Ran into this discrepancy myself. On top that, what seemed also odd to me were the "dots" (tittle, period, semicolon) where oversized becomes hollow in the middle, like it cancels out itself. No other shape I've tried did that. And browsers surprisingly agreed on this.

Made few shots and playground for that back then: https://x.com/myfonj/status/1870178380831732160

Look at V in Love. It looks like bug in Chrome.

OT: really love the design of this blog. Simple, clear and content first.

Ya! So many posts with clear presentations of css/svg/canvas.

The Daily Sketch series or 'CSS Animation with offset-path' are equally fun.

Neat! It's unfortunate that the rendering is so different between browsers.

Have you tried the same thing with shadows? They can also be stacked, I believe.

Shadows have to be spread in a circle to achieve an outline, so the general shape will converge to roughly a circle, barely following the shape of the text.

First thing I thought to do was add an emoji to the content. But it just shows the unknown char rectangle. I was hoping for magic, I guess.

An emoji rendered for me but not any of the outline stuff, just a bare emoji.

It works if you use Noto Emoji as the font.

People should quit trying to make CSS a drawing tool--it is not--and start learning how to use SVG instead or images.

Art is often made from clever use of things that were not intended to make art. Let them have fun.

Look at V in Love. It looks like bug in Chrome.

Art is often made from clever use of things that were not intended to make art. Let them have fun.

The article literally says "it's not well-suited for production usage" so I don't really see the reason for the objection here. It's an experiment.

I would rather have both working together:

My example: https://codepen.io/spartanatreyu/pen/xggjWz

------------------------------------------------

Overall, CSS tends to be the better tool for the job.

SVG has better paths and more interesting filters, but it's held back by a few critical issues.

1. A small amount of filters are not hardware accelerated in firefox/servo's webrender engine, which causes them to fallback to software rendering. Usually it just freezes the web page for a second or two while the image software renders before returning to normal performance, but if you try to animate any of the values it locks up the entire page.

That basically animated SVGs with filters a no-go.

2. Safari doesn't draw SVGs properly, it has a built-in "performance budget" where it just stops drawing the rest of the SVG if it isn't finished within a split second. Which is fine for something like an icon, but terrible for things like the main feature graphic / background of a page.

Meanwhile CSS keeps getting better. Its filters are improving (filter, mix-blend-mode, backdrop-filter), and its animations are improving too (keyframes + animation, transition, offset, custom-properties + @property's syntax, scroll-timeline, cross-document view transitions).

The two things that CSS is worse at than SVG are:

1. Paths (in which case, you can just put SVG paths into your page and style them with CSS for anything more complex than a static stroke/fill anyway)

2. Generating textures (which you can't guarantee look consistent thanks to Safari, so you're usually better off sending a hand optimized texture over the wire anyway)

If you have a lot of "images" with such effects to generate from dynamic text, using SVG makes no sense, is vastly more complex and less flexible than the solution here.

I'd send you the link to the person who made a 3d renderer in pure CSS, with a very slow render of lara croft, but Cohost shut down

This could actually be cool for display text like a headline. I don’t think that’s only for images.

I would think that quite a few powerful new ideas have come purely from abusing and bashing around older ideas.

Thanks for the explanation. I’ve moved away from frontend work in 2018, and I really have no idea what CSS can do anymore! So much of the CSS in this page looks cryptic to me.

Kudos to the author for posting something cool and new in the age of standardised styles.

css-doodle's syntax has a lot of non-standard-CSS stuff in it. All the @ things are extensions.

firefox looks like an SDF (shortest distance to the object), I'm not sure what the chrome one is...

I would assume they are just drawing the outline, not performing any distance calculations, and the differences are just a result of different linejoin choices. [1]

[1] https://www.w3.org/TR/fill-stroke-3/#stroke-linejoin

css-doodle's syntax has a lot of non-standard-CSS stuff in it. All the @ things are extensions.

A robust rebuttal. It’s how i prefer all of my images

The HTML is invalid. <div id="monalisa" />

Ya! So many posts with clear presentations of css/svg/canvas.

The Daily Sketch series or 'CSS Animation with offset-path' are equally fun.

Shadows have to be spread in a circle to achieve an outline, so the general shape will converge to roughly a circle, barely following the shape of the text.

An emoji rendered for me but not any of the outline stuff, just a bare emoji.

It works if you use Noto Emoji as the font.

A robust rebuttal. It’s how i prefer all of my images

This could actually be cool for display text like a headline. I don’t think that’s only for images.

The HTML is invalid. <div id="monalisa" />

I would assume they are just drawing the outline, not performing any distance calculations, and the differences are just a result of different linejoin choices. [1]

[1] https://www.w3.org/TR/fill-stroke-3/#stroke-linejoin

I'd imagine that at some point during the text rendering process, they have to generate an SDF of the text they want to render (it's what I did when I wanted to manually render text anyway). If they do, then they can generate the extra text-width lines basically for free, just fill everything with distance less than the property.

I may be entirely wrong though, I don't know in detail how browsers render stuff

If you have a lot of "images" with such effects to generate from dynamic text, using SVG makes no sense, is vastly more complex and less flexible than the solution here.

I may be entirely wrong though, I don't know in detail how browsers render stuff

You don't generate images, you just embed SVG nodes in the DOM. From the browser's perspective SVG and HTML elements are just two different types of element.

SVG is not great for text - HTML has more features - but for display text it's OK.

Miter join (Safari) VS round join (Chrome)

Made few shots and playground for that back then: https://x.com/myfonj/status/1870178380831732160

I would rather have both working together:

My example: https://codepen.io/spartanatreyu/pen/xggjWz

------------------------------------------------

Overall, CSS tends to be the better tool for the job.

SVG has better paths and more interesting filters, but it's held back by a few critical issues.

That basically animated SVGs with filters a no-go.

The two things that CSS is worse at than SVG are:

1. Paths (in which case, you can just put SVG paths into your page and style them with CSS for anything more complex than a static stroke/fill anyway)

2. Generating textures (which you can't guarantee look consistent thanks to Safari, so you're usually better off sending a hand optimized texture over the wire anyway)

The article literally says "it's not well-suited for production usage" so I don't really see the reason for the objection here. It's an experiment.

Stroke expansion is a complex topic, with more than one reasonable result (subjective preferences), and a whole lot of corner cases and incorrect answers.

Firefox has chosen to expand based on distance at all points, which is one of the reasonable answers and probably the most general one; a cusp then expands to a curve.

There aren't many "corner" cases in Firefox :D

(Yes, it could technically be infinite corner cases)

You don't generate images, you just embed SVG nodes in the DOM. From the browser's perspective SVG and HTML elements are just two different types of element.

SVG is not great for text - HTML has more features - but for display text it's OK.

I'd send you the link to the person who made a 3d renderer in pure CSS, with a very slow render of lara croft, but Cohost shut down

I would think that quite a few powerful new ideas have come purely from abusing and bashing around older ideas.

It is pretty much the entire hacker ethos. "I have this thing that does something but not what I need, but with some tinkering it now does what I need" or even "I have this thing, but I'm just going to see what else I can make it do whether it is useful or not but solely because I can"

Probably writing itself was originally a hack.

There aren't many "corner" cases in Firefox :D

(Yes, it could technically be infinite corner cases)

Probably writing itself was originally a hack.

I used to see that retro multi-stroke text effect quite often and tried to replicate it using the CSS text-stroke property, but the results never quite matched. Because text-stroke accepts a single value, stacking elements was the only workaround I could think of, though it didn't seem to work.

One evening late last year, I was eager to give it another shot after seeing the text effect again in the book Graphic Japan : from woodblock and zen to manga and kawaii.

pattern from book Graphic Japan : from woodblock and zen to manga and kawaii

Text stroke effect from the book

I kept stacking several elements and accidentally varied the text-stroke-width for each layer. To my suprise, the result was getting closer this time.

--c: #cc0d55;
--n: @i(-1);

@grid: 36x1 / 240px;
@content: '✱';

position: absolute;
inset: 0;
font: 100px/0 sans-serif;
color: var(--c);
z-index: @I(-@i);

-webkit-text-stroke-color: @pn(--c, #f4e1e8);
-webkit-text-stroke-width: $em(.08n+.02(1-(-1)^n));

How it works

For different values of the text-stroke-width, browsers will automatically draw outlines of the charater, The larger you set the stroke width, the thicker the outline will get, while still maintain its original shape.

@grid: 7x1/ 360px auto noclip; @content: '✱'; font: 50px/0 sans-serif; color: transparent; -webkit-text-stroke-color: #cc0d55; -webkit-text-stroke-width: @i(*1.8px);

The next step is to use different colors and put them in order.

@grid: 12x1/ 100px ß #f4e1e8; @content: '✱'; position: absolute; inset: 0; z-index: @I(-@i); font: 50px/0 sans-serif; color: transparent; -webkit-text-stroke-color: @pn(#f4e1e8, #cc0d55); -webkit-text-stroke-width: @i(*3px);

The interesting part is how the browsers outlining the character shapes differently. FireFox offers more smoother rendering than in Chrome and Safari.

Another interesting part is when there are more text put inline, the character shapes will be merged.

/* ... */
@content: '秋收冬藏';

Trying different fonts

The final result really depends on the font you choose. To help experimenting with different fonts more quickly, I added the @google-font function for faster font loading.

--c: #cc0d55,#fff; @grid: 34x1 / 320px; @content: 'b'; font: 150px/0 @google-font(Matemasie); @place: center; z-index: @I(-@i); color: @pn(--c); -webkit-text-stroke-color: @pn(--c); -webkit-text-stroke-width: @i(-1, ease, *12px);

font-family: @google-font(Matemasie);
@content: 'b';

--c: #cc0d55,#fff; @grid: 30x1 / 320px; :after { content: 'Love'; position: absolute; } font: 80px/0 @google-font("Pacifico"); @place: center; z-index: @I(-@i); color: @pn(--c); -webkit-text-stroke-color: @pn(--c); -webkit-text-stroke-width: @i(ease, -1, *15px);

font-family: @google-font(Tangerine);
@content: 'Love';

--c: #fff9e0,#f1c550,#ff6600,#ce2525; --c: #cc0d55,#fff; @grid: 30x1 / 320px +2 ~0 -10%; :after { content: '+'; position: absolute; } @place: 50% 50%; font: 120px/0 @google-font("Cherry Bomb One"); z-index: @I(-@i); color: @pn(--c); -webkit-text-stroke-color: @pn(--c); -webkit-text-stroke-width: @i(ease, -1, *12px);

font-family: @google-font('Cherry Bomb One');
@content: '+';

Unfortunately, the performance is as bad as CSS filters, especially when the font-size is getting bigger, you may have noticed some flicking above. It's fine for experiments like this, or for generating images with css-doodle, but it's not well-suited for production usage.

More examples

Here are two more examples to play around with different colors and characters, generated with css-doodle, just for fun.

CodePen link for the first one: https://codepen.io/yuanchuan/pen/ogzarGo