Ever wondered how people get those nice image cards to show up when they share a link to their site? These images are part of the Open Graph protocol (https://ogp.me/). You add some metadata to your page in the form of meta tags and that's it.

Today, let's look at how you could deal with that image value.

Other solutions

Before going into how they're generated for jhey.dev, there are other ways you could do it. This list isn't exhaustive.

• Host and curate images yourself for pages. Create your image and point the meta tag at its hosted location.
• Generate the images at build time with Node using packages like Puppeteer and Sharp.
• Use an image CDN with clever customization tools like those on offer from Cloudinary.
• Something like Vercel's @vercel/og if you're using Vercel as your hosting provider.

These are all good solutions. I'm sure there are others. It kinda comes down to what's going to suit your design and setup.

Before, jhey.dev used the second of those to create images like this.

It can be quite a weighty solution. I wanted to reflect the article here in the bear's sunglasses though. The idea is that you create some HTML and use Puppeteer to open it and take a screenshot of it. Then save that and host it. This all happens in a node script that could get run post-build.

The use of an image CDN is quite appealing. Jason Lengstorf has a good write-up on using Cloudinary to auto-generate social images. This was the first time I recall seeing it done with generated URLs. It's a lovely solution.

Then Vercel announced @vercel/og built upon satori. This is the one that excited me. It's a balance between the URL solution and the control of HTML. I got a quick taste by integrating it into the Codu community site. And after seeing how good it was, I wanted it for my own site. But, I don't use Vercel. And switching hosting providers for social images seemed extreme. So, how can you do it?

https://www.learnwithjason.dev/blog/auto-generate-social-image/

https://vercel.com/docs/concepts/functions/edge-functions/og-image-generation

https://github.com/codu-code/codu/pull/92

That's it! It's wild to think how the web platform is evolving. All these new features and tools that are knocking down hurdles we've faced for some time.

Until next time, stay awesome!

Further reading

• An Intro to Trigonometric CSS Functions: Stephanie Stimac
• The Power (and fun) of Scope with Custom CSS Properties: CSS Tricks
• textPath: MDN
• textLength: MDN
• SVG circle decomposition to paths: Smashing Magazine

Check out the demo pen by Jhey (@jh3y) over on CodePen.

If you're not familiar with this API, I introduced it in "Building Chrometober". It allows you to drive CSS animations with scroll. The magic part is that this will all happen off the main thread. That means performant scroll-driven animations where JavaScript is optional.

It's currently experimental in Chrome. But, there is a polyfill that you can use. That's what powers today's demo.

The API has been through many changes. The compatibility data from MDN is a little inaccurate currently (That's what powers the <BrowserSupport> widget above). I'd recommend keeping an eye on the spec or the polyfill repo if you're interested in keeping up to date with things. Or keep in touch with me!

Drive type

At a high level, scroll-driven animations fall into two categories:

1. Those driven by scroll position using scroll-timeline.
2. Those driven by an element's position within its scroll container (scrollport) using view-timeline.

Today, we're concerned with the first of those. Driving animations based on scroll position.

Building this demo

First things first, we need that polyfill. Import this in a way that works for you. Here it is in a script tag.

<script src="https://flackr.github.io/scroll-timeline/dist/scroll-timeline.js"></script>

Up next, you need some elements to animate. A list with some images will work for what we want. For this demo, I've used picsum.photos for placeholder images:

<main>
  <ul>
    <li style="--x1: 2; --x2: 6; --y1: 1; --y2: 4;">
      <img src="https://picsum.photos/600/600?random=1" alt="">
    </li>
    <li style="--x1: 6; --x2: 8; --y1: 2; --y2: 4;">
      <img src="https://picsum.photos/600/600?random=2" alt="">
    </li>
    <!-- Obfuscated items -->
  </ul>
</main>

Now to lay them out in this grid-like manner. You have options here. You could use grid-template-areas and draw the layout in your CSS.

ul {
  grid-template-areas: ". a a a a . . . . ."
                       ". a a a a c c . ."
                       ". a a a a c c . .";
}
li:nth-of-type(1) {
  grid-area: a;
}

I'm not a huge fan of grid-template-areas though. They sometimes don't play nice.

You may have noticed the inline styles in the markup above:

<li style="--x1: 2; --x2: 6; --y1: 1; --y2: 4;">
  <img src="https://picsum.photos/600/600?random=1" alt="">
</li>

They define the coordinates for grid position. It might seem verbose to write these out. But, I like to lean into the use of custom property scope here. You can likely get away with positioning the main items and then rely on grid-auto-flow: dense too. Another approach would be having these coordinates in a JavaScript object. Then you can use whatever templating language you like to generate the markup and inline styles.

Anyway, back to the styles. Taking the custom property approach, you can scope the styles for the items:

ul {
  --big-tile-size: 50vmin;
  --rotation: 270deg;
  --scale: 0.4;
  --tile-size: calc(var(--big-tile-size) / 3);
  display: grid;
  grid-template: repeat(9, var(--tile-size)) / repeat(9, var(--tile-size));
  gap: 1vmin;
  transform:
    translate(-50%, -50%)
    scale(var(--scale))
    rotate(0deg);
}
li {
  grid-column: var(--x1, auto) / var(--x2, auto);
  grid-row: var(--y1, auto) / var(--y2, auto);
}

Check out the demo pen by Jhey (@jh3y) over on CodePen.

Now the grid is starting to take shape. There are custom properties to define the behavior of the grid and it's time for animation. This is where the --scale and --rotation properties are going to come into play.

You need to animate two things:

1. The layout's scale and rotation.
2. The image rotation to counter the layout rotation.

But, you don't need two keyframes for that. You can share one set using custom properties.

@keyframes scale-up {
  0% {
    transform:
      translate(-50%, -50%)
      scale(var(--scale))
      rotate(0deg);
  }
  100% {
    transform:
      translate(-50%, -50%)
      scale(1)
      rotate(var(--rotation));
  }
}

The images set their direction to counter the layout rotation and use the same keyframes:

img {
  --rotation: -270deg;
  --scale: 1;
}

Now you can apply the animation. Let's set the iteration count to infinite to see it on loop.

ul, img {
  animation: scale-up 10s infinite ease-in-out alternate;
}

Check out the demo pen by Jhey (@jh3y) over on CodePen.

Ready for the last piece of the puzzle? Let's drive it with the body's scroll position.

ul, img {
  animation-timeline: scroll(root);
  animation: 1s scale-up both ease-in;
}

Yep. That's all you need for a scroll timeline. Remove the iteration count from our animation and set the animation-fill-mode to both. The animation-timeline property is set to scroll(root). This defines that the animation will get driven by the scroll of the root scroller. In this case, that's the body. To tie it all together, we fix the position of our layout and set the body height to the amount we'd like to scroll.

body { height: 300vh; }

And we get the end result!

Check out the demo pen by Jhey (@jh3y) over on CodePen.

Driving CSS animation with scroll and no JavaScript is an exciting prospect. I'm excited for it to make its way into browsers. Let's hope future versions of the spec include the ability to trigger or ease the animations.

Bonus (GSAP Solution)

The scroll-driven animations API is in its early stages. Someone did reach out asking if you could ease the scroll. If it were me, I'd be reaching for GreenSock. The ScrollTrigger plugin handles this use case well with the scrub property.

You have to adjust your implementation a little. But, you can power the whole thing with this block of JavaScript:

import gsap from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger"

gsap.registerPlugin(ScrollTrigger)

gsap.defaults({
  duration: 2,
  ease: "power1.inOut"
});

const rotate = 270

gsap
  .timeline({
    scrollTrigger: {
      scrub: 1, // smooth scrubbing catch up duration
    }
  })
  .to("ul", {
    scale: 1,
    rotate,
  })
  .to(
    "img",
    {
      rotate: -rotate
    },
    0
  );

Check out the demo pen by Jhey (@jh3y) over on CodePen.

That's it! The CSS scroll-driven animation API is an exciting one. I've been playing with it a bunch seeing what kind of things you can do with it. I'm excited to see it in your hands! Until that API matures though, solutions like GreenSock's ScrollTrigger are fantastic.

Stay awesome!

Further reading

• Building Chrometober: web.dev
• Scroll Animations Spec: CSSWG
• Animation Timeline Browser Support: caniuse.com
• Demo tweet: Twitter
• Demo link: CodePen
• Demo Collection: CodePen
• GSAP ScrollTrigger: GreenSock

Anyway. This isn't a history lesson. There was a recent kerfuffle on social media about whether to "rebase" or "merge". And it got me thinking, "For real? Do you know what this was like before?". Commit message history was the least of people's worries ha. I've worked in a lot of different setups and seen it done in all sorts of ways. There's no one workflow to rule them all. That's the price of Git being feature rich.

In case you wondered, I'm team rebase for what it's worth.

GUI vs. CLI

To be honest, I haven't used a GUI app for Git in years. Nothing says that another machine is going to have your GUI app available. This exact scenario pushed me the CLI way when I had to start SSH'ing into remote machines for a role. The deep end will skill you up quicker than anything haha. That said, you can’t take your Git aliases with you.

Aliases

Creating Git aliases can save you a lot of time. Pushing something up? gpu is quicker to type than git push. Over time, it adds up.

How do you write an alias? That depends on how you're set up. You could write them into your .gitconfig. I like to set them up with the command line shell. I use ZSH and these are my current aliases. I do use yolo a bunch as part of the forking workflow.

#
# Git aliases
#
alias gs="git status"
alias gba="git branch -av"
alias gch="git checkout"
alias gca="git commit -a -m"
alias gaa="git add --all"
alias gau="git remote add upstream"
alias gfu="git fetch upstream"
alias gpl="git pull"
alias gpu="git push"
alias yolo="git push --force"
alias yolos="git push --force && say That was sneaky!"
alias gps="git push && say You are awesome!"
alias gcl="git clone"
alias glg="git log"
alias gst="git shortlog -sn"
alias gsl="git stash list"
alias gsc="git stash clear"

function gsb() {
  git checkout -b $1 upstream/main
}
function gdb() {
  git branch -d $1
  git push origin :$1
}
function gas() {
  git stash apply stash@\{$1\}
}
function grb() {
  git rebase -i HEAD~$1
}

ZSH supports functions and they're great for creating aliases that handle parameters. I have a rebase alias that allows me to do things like start an interactive rebase of the last 3 commits. Instead of git rebase -i HEAD~3, it's grb 3. Easy.

Workflow

Rebase or merge? Whatever you prefer. The goal is to get code into a code base. I can't remember where seeing a merge commit in a Git log has been an issue. That said, I prefer not seeing them in there. It's easier to read depending on the amount of traffic.

Where possible, I try to follow the "Forking workflow". To me, that feels the most risk-averse. Contributors can only break their own yard.

Powered by my aliases, I'll likely do something like this:

# Clone my fork
gcl https://github.com/dev/awesome-project.git
cd awesome-project
# Add an upstream remote
gau https://github.com/official/awesome-project.git
# Fetch the upstream
gfu
# Start a new branch for what I'm doing
gsb FEAT-123/new-component

And then I'll crack on with a feature or something. I'll likely make a bunch of changes along the way. And I'll write myself messages in the commits:

gca "update"
gca "try different looping method"
gca "pre lunch commit"
gca "check in before the refactor storm"

The idea is that these atomic messages help me out. If I needed to roll back to some point in time, I could. I'll tidy them up before I push. No one needs to know about the commit I made before lunch.

When everything looks good and I'm ready to push, I'll do an interactive rebase. I'll squash all the meta-commits making it easier for others to read the commit history. If it feels like there are useful checkpoints, I'll leave them in. But, this kinda leans towards the ideal practice of keeping things atomic. If you start creating a bunch of checkpoints, they could likely all be pull requests. And it's easier for someone to review smaller changes.

# interactive rebase last 4 commits
grb 4
# push those changes
yolo

You can use the "Squash and merge" button on GitHub. I recommend it. Thing is. This habit started for me way before that feature was available. It's not a bad habit to have. I'll squash my commits, make sure I'm up to date with the official repo, and push.

That's it. At the end of the day, find a workflow that's comfortable for you and be mindful of others. Keep things atomic. I mean, as long as the code gets into the repo, that's the main thing. That's the goal. Heck, write an alias that acts like FTP if you want (Maybe don't do this).

function ftp() {
  git commit -a -m "FTP"
  git push --force
}

Stay Awesome!

Further Reading

• Git aliases: Git
• Forking workflow: Atlassian
• Rebase and push: GitLab
• ZSH Functions: ZSH Sourceforge
• Oh My ZSH: Oh My ZSH

How you might solve this today

You've definitely got options. Before we go down the CSS route, you could use images. The least maintainable route could be creating an image each time you need to change the text. Make sure to use the alt attribute to describe the text that's shown.

Or you could use an inline SVG. SVG has a textPath element. For the most part, it's pretty good. You give it some text and a path to lay that text on.

<svg
  viewBox="0 0 100 100"
  xmlns="http://www.w3.org/2000/svg"
>
  <path
    id="circlePath"
    d="
      M 10, 50
      a 40,40 0 1,1 80,0
      40,40 0 1,1 -80,0
    "
  />
  <text>
    <textPath href="#circlePath">
      Your text here!
    </textPath>
  </text>
</svg>

This route does pose a couple of hurdles. First, you need a path. You can't pass reference to a circle. That means converting a circle to a path.

<path
  d="
    M (CENTER_X - RADIUS),CENTER_Y
    a RADIUS,RADIUS 0 1,1 (2 * RADIUS),0
    RADIUS,RADIUS 0 1,1 (-2 * RADIUS),0
  "
/>

Next, you need to choose whether you use the textLength attribute of textPath. This can spread the text around the path. The value of this will be the circumference.

<textPath
  href="#circularPath"
  textLength={Math.floor(Math.PI * 2 * RADIUS)}
>
  Your text here!
</textPath>

Put everything together and you'll get something like this.

Check out the demo pen by Jhey (@jh3y) over on CodePen.

In this demo, you can change the text and see how the use of textLength plays a part. You can also change the radius and font size. A neat part of using SVG is that we have something scalable. Another cool feature is that the text will follow the path direction. That makes it easy to flip whether the text is inside or outside of the path. You can do that by changing the sweep flag of an arc between 1 and 0.

So SVG can do the job, right? Well, kinda. But, if you try punching in some longer text, that radius will need adjusting. And, at this point, you're prodding in the dark.

For the most part, working in code, we're somewhat wired to assume some degree of accuracy. That is, minus some rounding and other JavaScript quirks. So for me, punching numbers in until it "looks right", sometimes doesn't sit quite well with me.

Could you be more accurate with CSS? A rudimentary approach could go like this:

1. Split text into span elements for each character.
2. Set an inline custom property for the character index.
3. Set an inline custom property on the parent for total characters.
4. Using CSS calc, transform each span by rotating and then translating it using its index.
5. If this will be visible to screenreaders, hide all the characters with aria-hidden. Then create a visually hidden span with the full text inside it.

Here's how the HTML might look:

<span
  class="text-ring"
  style="--total: 15;"
>
  <span aria-hidden="true">
    <span style="--index: 0">Y</span>
    <span style="--index: 1">o</span>
    <span style="--index: 2">u</span>
    <!-- Obfuscated markup -->
  </span>
  <span class="sr-only">
    Your text here!
  </span>
</span>

And the CSS could go a little like this:

.text-ring {
  position: relative;
}
.text-ring [style*=--index] {
  font-size: calc(var(--font-size, 2) * 1rem);
  position: absolute;
  top: 50%;
  left: 50%;
  transform:
    translate(-50%, -50%)
    rotate(calc(360deg / var(--total) * var(--index)))
    translateY(calc(var(--radius, 5) * -1ch));
}

How do you calculate that radius though? We're still prodding in the dark. Try adjusting things until they "look right" in this demo.

Check out the demo pen by Jhey (@jh3y) over on CodePen.

Enter trigonometric functions

Try not to fear the word "trigonometric". I know, I know. When I hear it, I start thinking of "Differential equations", "Mechanics", and so on. But, some Math and leaning into font behavior is going to get us a solution.

You may have noticed the demos above use a monospace font. The benefit of doing so is that you know every character will be the same width. Think about the circle in a different way. It's actually lots of triangles around a point. A monospace font means every "side" of our circle is the same width. If you have the width of a side and the inner angle, you can calculate the hypoteneuse. That hypoteneuse is our radius!

const TOTAL_CHARACTERS = 15
const INNER_ANGLE = 360 / 15
const LENGTH_OF_SIDE = 1 // 1ch
const RADIUS = LENGTH_OF_SIDE /
  Math.sin(INNER_ANGLE / (180 / Math.PI))

A neat trick here is to define the side width using the "ch" unit. That's equal to the width of a "0" in our font. And because a monospace font is being used, that'll be the width of every character. That means we'll get a radius in "ch" units. But, changing the font-size will behave in a way that scales the text ring. Neat!

That snippet of JavaScript above gets us the radius and now we can set that in our CSS. The bonus is that if you're doing static markup generation, you can pass all the details in as inline styles. Here it is in a React component. You might server-side render this or use it in something like Astro (What this site uses).

const TextRing = (text) => {
  const CHARS = text.split('')
  const INNER_ANGLE = 360 / CHARS.length
  return (
    <span
      className="text-ring"
      style={{
        '--total': CHARS.length,
        '--radius': 1 / Math.sin(INNER_ANGLE / (180 / Math.PI))
      }}
    >
      {CHARS.map((char, index) => (
        <span style={{'--index': index }}>
          {char}
        </span>
      ))}
    </span>
  )
}

For the most part, this will do the trick. But, what if you don't like the feel of dictating your layout styles in JavaScript? Well, CSS might be able to help with that very soon.

Introducing CSS trigonometry

Trigonometric functions are coming to CSS. This will give you access to functions such as sin, cos, and tan within CSS. They're already available in Firefox and Safari. They're poised to ship in Chromium 111. Be sure to check out the "CSS Values and Units Module Level 4" spec. The introduction of these functions in CSS opens up some exciting opportunities. For example, you could use them in layouts or the timing of loading animations.

What does this mean for our circular text? CSS can now do the radius calculation. You no longer need to couple the layout styling to some JavaScript. The --radius is now calculated using sin in our CSS.

.text-ring {
  --character-width: 1; /* In "ch" units */
  --inner-angle: calc((360 / var(--total)) * 1deg);
  --radius: calc(
    (
      var(--character-width, 1) /
      sin(var(--inner-angle))
    ) * -1ch
  );
}
.text-ring [style*=--index] {
  transform:
    translate(-50%, -50%)
    rotate(calc(var(--inner-angle) * var(--index)))
    translateY(var(--radius, -5ch));
}

Plug that into our demo and we get the right radius.

Check out the demo pen by Jhey (@jh3y) over on CodePen.

If you're not in a supporting browser, you should see a warning message. You can detect CSS trigonometric function support in CSS with:

@supports (top: calc(sin(1) * 1px)) {
  /* Insert styles */
}

Or in JavaScript with:

const canTrig = CSS.supports('(top: calc(sin(1) * 1px))')

For the finishing touches, let's make our text ring spin:

@media (prefers-reduced-motion: no-preference) {
  .text-ring {
  	animation: spin 6s infinite linear;
  }
  @keyframes spin {
    to {
      rotate: -360deg;
    }
  }
}

And that'll do it. Putting it all together, we can make a demo like this one.

Check out the demo pen by Jhey (@jh3y) over on CodePen.

In this demo, CSS trigonometric functions get used if supported. If not, we fall back to setting the --radius with JavaScript. For now, you could copy the HTML and CSS you need until CSS trigonometric functions get full support. The next step is getting sibling-count and sibling-index in CSS. There's a proposal for it in the CSSWG repo. Then we wouldn't need the inline custom properties anymore.

That's it! It's wild to think how the web platform is evolving. All these new features and tools that are knocking down hurdles we've faced for some time.

Until next time, stay awesome!

Further reading

• An Intro to Trigonometric CSS Functions: Stephanie Stimac
• The Power (and fun) of Scope with Custom CSS Properties: CSS Tricks
• textPath: MDN
• textLength: MDN
• SVG circle decomposition to paths: Smashing Magazine
• Demo Collection: CodePen