DEV Community: Rob OLeary

Eleventy - Is it time to upgrade to version 3?

Rob OLeary — Sun, 08 Sep 2024 10:08:42 +0000

Version three of Eleventy has some exciting new features such as async configuration, virtual templates, and ECMAScript Modules (ESM) support. I am keen to upgrade, it unlocks some possibilities for features I'd like to work on!

Version three is still in pre-release. It has reached it first beta (v3.0.0-beta.1). It should be in decent shape, but you are going to be somewhat of a canary tester if you use a pre-release version. You may have a smooth ride or you may hit speedbumps along the way depending on your particular configuration.

After reading some accounts of other people upgrading (Raymond Camden, Helen Chong, and Bob Monsour), it encouraged me to give it a go! I set myself a time limit of three hours. I will need to shelf it for another time if it takes longer than that.

How to upgrade

I made a new branch of my website and followed the instructions in the v3.0.0-beta.1 release notes:

I installed Eleventy v3 beta. You should do this first. I use pnpm as my package manager, so I ran pnpm add @11ty/eleventy@beta to add it as a dependency.
I took the extra step of uninstalling the previous version of eleventy because I wanted to ensure my npm scripts would work. I ran pnpm remove @11ty/eleventy.
I installed the upgrade helper plugin with pnpm add @11ty/eleventy-upgrade-help@3.
I added the plugin to my configuration file (as below). I made sure that it was the last addPlugin() call.

// eleventy.config.js
const UpgradeHelper = require("@11ty/eleventy-upgrade-help");

module.exports = function(eleventyConfig) {
  // If you have other `addPlugin` calls, UpgradeHelper should be listed last.
  eleventyConfig.addPlugin(UpgradeHelper);
};

Version three supports both CommonJS and ESM. I should not need to change anything in theory. Hopefully, I will dodge the breaking changes.

I ran Eleventy in serve mode. It spat out an error! Let's see if I can fix things up...

Upgrade issues

I encountered three errors and 1 warning.

Error 1 - Tabs are prohibited in YAML frontmatter

The first issue was a complaint about having tabs in YAML frontmatter. It was pointing at the tag.njk file.

[11ty] Problem writing Eleventy templates:
[11ty] 1. Having trouble reading front matter from template ./src/pages/tag.njk (via TemplateContentFrontMatterError)
[11ty] 2. tab characters must not be used in indentation (10:1)
[11ty] 
[11ty]   7 | stylesheet: "/assets/stylesheet ...
[11ty]   8 | eleventyComputed:
[11ty]   9 |   title: Posts tagged with “{{  ...
[11ty]  10 | →permalink: /blog/tag/{{ tag |  ...
[11ty] ------^ (via YAMLException)
[11ty] 
[11ty] Original error stack trace: YAMLException: tab characters must not be used in indentation (10:1)
[11ty] 
[11ty]   7 | stylesheet: "/assets/stylesheet ...
[11ty]   8 | eleventyComputed:
[11ty]   9 |   title: Posts tagged with “{{  ...
[11ty]  10 | →permalink: /blog/tag/{{ tag |  ...
[11ty] ------^

The js-yaml library was upgraded from version three to version four. It is more strict on enforcing formatting. Tabs in YAML frontmatter will now break the build.

Replacing the tab in the frontmatter with 2 spaces solves this issue. Thankfully it was only one instance in my project! So it was a quick fix.

Error 2 - Failed version check of Sass plugin

The next issue came from the eleventy-sass plugin that I use for adding Sass support to Eleventy. The plugin has a version check. It does not support version three yet, so it breaks the build.

Rather than getting into the weeds, I just removed it as a plugin from my config. This got rid of the error but also removed the styles from my website! Everything looks rather bland now!

I will circle back later to see if there is a quick solution to this.

Error 3 - A peciular `TemplateContentPrematureUseError` error

The next error I recieved was a TemplateContentPrematureUseError error as below.

[11ty] Unhandled rejection in promise:
[11ty] Tried to use templateContent too early on ./src/posts/new/2024-08-17-code-embeds/index.md (via TemplateContentPrematureUseError)
[11ty] 
[11ty] Original error stack trace: TemplateContentPrematureUseError: Tried to use templateContent too early on ./src/posts/new/2024-08-17-code-embeds/index.md
[11ty]     at Object.get [as templateContent] (file:///home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/@11ty+eleventy@3.0.0-beta.1/node_modules/@11ty/eleventy/src/Template.js:612:14)
[11ty]     at Object.memberLookup (/home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/nunjucks@3.2.4_chokidar@3.6.0/node_modules/nunjucks/src/runtime.js:201:17)
[11ty]     at eval (eval at _compile (/home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/nunjucks@3.2.4_chokidar@3.6.0/node_modules/nunjucks/src/environment.js:527:18), <anonymous>:83:15)
[11ty]     at iterCallback (/home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/nunjucks@3.2.4_chokidar@3.6.0/node_modules/nunjucks/src/runtime.js:236:11)
[11ty]     at next (/home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/nunjucks@3.2.4_chokidar@3.6.0/node_modules/nunjucks/src/lib.js:258:7)
[11ty]     at eval (eval at _compile (/home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/nunjucks@3.2.4_chokidar@3.6.0/node_modules/nunjucks/src/environment.js:527:18), <anonymous>:127:1)
[11ty]     at /home/rob/programming/workspace/websites/roboleary-v0_3/node_modules/.pnpm/eleventy-plugin-killer-filters@0.6.0/node_modules/eleventy-plugin-killer-filters/eleventy.config.js:39:9
[11ty]     at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

The error pointed to a markdown post. There was nothing special about that post. I removed the post to see if that changed things, it didn't! It threw the same error but pointed to another post! That's weird!

After digging through the issues of the Eleventy repo, I discovered that the error has nothing to do with markdown posts. My situation matched the explanation given in the issue - Tried to use templateContent too early in eleventy 3.0.0-alpha.3 on rerender. The actual cause of the issue is the htmlAbsoluteUrls filter that is supplied by the official RSS plugin. I use that filter in a template (feed.njk) to generate my RSS feed. When I deleted feed.njk, the error went away!

With those issues overcome temporarily, my website appeared to running in serve and build modes correctly.

In order for me to publish my website using version 3 beta, I would need to do the following to have my website in the exact same state as before:

To restore my styles, I would need to update the eleventy-sass plugin. It appears that the plugin author has made a new major version supporting Eleventy v3. It requires Node.js v22+ and uses an experimental Node feature. I'm not sure I want to go down that road. And I would need to test it to check on the stability. I will need to delve deeper to make a decision.
Probably the cleanest solution for the RSS feed template (feed.njk) is to convert it to a virtual template. This is not something I want to rush into. My feed has some conditional logic, so it is not a quick conversion. I'd need to test it properly to ensure that the outputs match.

Revising those 2 facets of my website would definitely push me over my 3 hour limit. I will need to shelf this for now.

I can use the time left over to do a quick reconnaissance on converting my configuration to ESM. That is something I'd like to get to eventually also.

What about converting your eleventy configuration to ESM?

My configuration file is split into approximately 40 files, and I have quite a few data files. To feel out the process, I wanted to work with a small subset of my website. I deleted the majority of the pages, templates and markdown files that were using a lot of filters and shortcodes. I edited my config to use the minimum number of imports and was able to get things running.

The only big issue I found was with importing JSON files. You should be able to import a JSON file in Node with the following syntax: import data from './data.json' assert {type: 'json'};. Importing a JSON file in Node is still an experimental feature, it can cause issues.

Eleventy does not handle JSON imports gracefully yet, the problem is outlined in the issue - Import attributes not yet supported (Error thrown from acorn dependency). In serve and watch mode, JSON imports crash operation. You cannot ignore the issue.

There is a workaround with module.createRequire. It will permit importing a JSON file like you would in CommonJS:

import { createRequire } from "node:module";
const require = createRequire(import.meta.url);
const data = require("./src/data/site.json");

You could convert your JSON files to JavaScript files also if you prefer. I guess that when Node fully supports JSON imports, this issue will be resolved downstream eventually also.

Conclusion

I got most of the way through upgrading to version three of Eleventy. It will entail rewriting a couple parts of my website for me to get over the line. I don't have more time to give to that effort right now. I will favour a refresh of my website before I follow through with the upgrade.

Thanks to all the folks who have worked hard on this release! 🙌

Written by Rob O'Leary

Subscribe to RSS feed for the latest articles.

How to create a slick CSS animation from Alien

Rob OLeary — Wed, 29 May 2024 11:30:00 +0000

The title sequence for Alien is iconic. It sets the mood of the movie perfectly. Let's see how we can recreate it as a web animation!

TLDR

You can watch the title sequence on YouTube.

Here is the finished animation.

About the title sequence

The title is unsettling. It opens with a still scene of far away shot of planet and the camera is slowly panning across it. Slowly some disjointed bits of the title fade into view turning from a bluish hue to white. There is exaggerated spacing between the letters, so that when the bits of the letters finally resolve to a word, it still feels odd to recognize it as a word. It is backed by a moody instrumental.

The typeface is san serif. In an interview with The Art of The Title, the Title Designer Richard Greenberg says the following about the typeface:

It’s probably a slight variation on Futura, but it wasn’t custom. It was incredibly simple, but it struck a chord. Maybe because it was attached to one of the most frightening movies ever made!

The typeface probably is Helvetica Black. I have used a similar font called HomepageBaukasten Bold in my implementation.

You can read the full interview with Richard Greenberg to learn more about the design of the title sequence.

The animation

The duration of the title sequence is 2 minutes. The animation has 3 parts:

Background pan - The background is panning slowly to the right. When it reaches a point far to the right, it fades out. This runs for the duration of the title sequence.
Credit reveal - Credits of the crew are faded in and out. I only included a credit for for Ridley Scott to fill the void at the beginning. I wanted to keep it as simple as possible. This occurs 5 seconds into the title sequence, and has a duration of 4 seconds.
Title reveal - The title "ALIEN" is revealed segment by segment of each letter. This beings 12.5 seconds into the title sequence. A new segment is revealed approxmiately every 4 seconds.

A good starting point is to set up some CSS variables to mark out some key values to build a timeline around. It is the third part that has the most going on and has element relying on each other. This is what I set-up:

:root {
    /* begining point of title reveal */
  --animation-delay-title-reveal: 12.5s;

    /* the delay between animation of each segment in title reveal */
  --animation-delay-segment: 4s;

    /* the duration of animation of each segment in title reveal */
   --animation-duration-segment: 3.75s;
}

Let's go through each animation part now.

Part 1 - The background pan animation

The key to getting this background pan animation right is the having an eye-catching image with a decent resolution. We only want to display a cross-section of the image zoomed in. Therefore it needs to look good up close.

I created the background image using a composite of 2 space images I found from Unsplash. The main image is a solar ecliplse. I painted in the distinctive orangish hue and touched it up to get it closer to the original.

Below is the finished background image. The green box in the figure below shows the section we display as the background.

The middle of the image is used as the background, desingated by the green box

We want the background to be responsive but show that same cross section across all viewport sizes. Similar to a movie player, we can create a letterboxed appearance on smaller screen sizes.

To do this we make the body a grid and center the "title" div that has the background image. We give it a fixed aspect ratio (1920:1080) that matches the background image. We zoom in on the section by doubling the size of the background background-size: 200%; and center it vertically using background-position: 0% 50%;.

body {
  display: grid;
  overflow: hidden;
  height: 100dvh;
  margin: 0;
  background-color: black;
  place-items: center;
}

.title {
  width: 100%;
  max-width: 1920px;
  aspect-ratio: 1920 / 1080;

  background: black;
  background-image: url("img/bg.webp");
  background-size: 200%;
  background-position: 0% 50%;
}

The key to the animation is that the image has overflowed the viewport -- half of it is out of view on the right-hand side. To animate it, we want to change the X value of background-position to shift the background horizontally.

@keyframes bg-scroll {
  to {
    background-position: 200% 50%;
  }
}

Here is a simplified example of this animation part.

In the final version, a second animation is added to fade out the title at the end of the sequence.

.title {
  animation-name: bg-scroll, fadeout;
  animation-duration: 210s, 1s;
  animation-timing-function: linear, ease-out;
  animation-fill-mode: forwards, forwards;
  animation-delay: 0s, 120s;
}

@keyframes fadeout {
  to {
    opacity: 0;
  }
}

You may notice that the duration of the bg-scroll animation is over 3 and half minutes (210 seconds). Why is that? The easing is linear, we want a constant rate for the pan. However to compensate for not having the perfect image, I increase the animation-duration so that it pans close to the edge of at a slow constant pace. The second animation fadeout effectively hides the entire title at 2 minutes. Probably the better way to get to a perfect result would be to tweak the values for background-size and background-position, I just found this the quickest route to getting the desired outcome.

Part 2 - Credit reveal animation

We to show the credit for "Ridley Scott" for 3+ seconds and then hide it. We are animating the opacity of the element. Nothing unexpected here I would say!

p {
  animation: show-credit 4s;
  animation-timing-function: ease-in-out;
  animation-delay: 5s;
}

@keyframes show-credit {
  10%,
  100% {
    opacity: 1;
  }
}

Part 3 - The title reveal animation

In order to animate the title, we need cut up the letters into individual segments. This is the tricky part.

The actual animation is fairly straightforward. We are transitioning the background-color from transparent to a blueish hue to white finally.

Initially, I animated opacity also, but I found setting the intial background-color as transparent and changing the value to blue and then white matched the original.

@keyframes reveal-bg-color {
  0% {
    background-color: transparent;
  }

  33%,
  100% {
    background-color: blue;
  }

  100% {
    background-color: white;
  }
}

It was just a case of playing with the keyframes and easing to get the exact feel right.

We can use the aforementioned CSS variables to place each segment animation at the correct point in the timeline using animation-delay. We do a calcuation using these variables and multiply it by an ordinal number as below:

/* second segment to show - diagonal leg of N */
.letter:nth-of-type(5) i:nth-of-type(3) {

  animation-delay: calc(
    var(--animation-delay-title-reveal) +
      (var(--animation-duration-segment) * 2) +
      (var(--animation-delay-segment) * 2)
  );
}

/* 3rd segment to show - vertical bar of L */
.letter:nth-of-type(2) i:nth-of-type(1) {

  animation-delay: calc(
    var(--animation-delay-title-reveal) +
      (var(--animation-duration-segment) * 3) +
      (var(--animation-delay-segment) * 3)
  );
}

If you want to learn how to cut up the letter into segments, read on.

Cutting up the letters into segments

As a starter, let's get the size and spacing of the title correct. The title has a small margin on the top and sides. The letters are evenly and widely distributed in the available space.

Let's take the basic HTML where we have each letter as its own element.

<h1>
    <div>A</div>
    <div>L</div>
    <div>I</div>
    <div>E</div>
    <div>N</div>
</h1>

We use a grid on the h1 to evenly divide the space with each grid item (letter) taking up 1 fractional unit (fr).

h1{
  display: grid;
  grid-template-columns: repeat(5, 1fr);
  justify-items: center;

  margin: 0 10%;
  margin-block-start: 1.25rem;

  /* other styles */
}

Here is what we got so far...

The 4 options for cutting up the letters are:

Create 3 versions of each letter stacked up. You can duplicate each letter with the ::before and ::after pseudo-elements sourcing the letter from a data-letter attribute e.g. <div data-letter="A">A</div>. Then, you can cut out a portion of the letter with clip-path to have 3 referencable segments of a letter. The limitation is that the letter 'E' requires 4 segments!
You can create the segments of the letter using multiple background-image instances utilising various gradients to create the shapes. Animating background-image is more challenging as you may need to repeat values for keyframes.
You could nest multiple elements into each letter div to represent a letter part and style each one. It could be any arbitary element such i to keep it short. It is more straightforward to animate an element rather than a background image. I think this is the easier option.
You could create the title as a text element in a SVG. Then transform each letter to a path. Then, you can divide each path into the segments required (more path elements). In the Killing Eve title sequence in this series, I converted a text element into individual path elements. You can read that if you are curious about that process.

Personally, I find it is the easiest editing the title as a SVG in Inkscape (approach 4). However, I will go for approach 3 to demonstrate how we can stick with HTML and do it all in the browser. The markup looks like this:

<h1>
  <!--since A has 3 segments, it contains 3 i elements -->
  <div>A<i></i><i></i><i></i></div>

  <!--since L has 2 segments, it contains 2 i elements -->
  <div>L</div>

  <!--other letters-->
</h1>

We want to position each i element absolutely, relative to each letter div. We can then style each i as an overlay on top of the letter.

h1 div {
  position: relative;
}

h1 div i {
  position: absolute;
  width: 100%;
  height: 100%;
  left: 0;
  top:0;

  /* hide the ones we are not interested in */
  opacity: 0;
}

h1 div i:nth-child(1) {
  /* this one is visible and can see letter underneath */
  background: green;
  opacity:0.3
}

Now we have a green overlay like below.

What I found easiest is to use a polygon clip-path and edit it in the devtools (Firefox in my case). For example I will add a triangle polygon to the element: clip-path: polygon(50% 0%, 0% 100%, 100% 100%);. We want the clip path points to be in percentages to ensure that it is reponsive.

In the devtools, I can position each of the points to match the outline of the left arm of the letter A. I need to add a fourth point by double-clicking on the line to match the shape. You can see the process in action in the video below:

This is the codepen with the segment of the letter A defined:

This process needs to be repeated for each segment. Approximately a dozen times. Once this is done, you can set the color of the h1 to transparent and then animate each segment in the correct order.

I have left the text content for each letter. I used clamp() with the font-size to make the title responsive to the viewport.

Alternatively, you could remove the text content. You would need to set the width and probably an aspect-ratio to emulate the x-height of the text.

Final thoughts

There was quite a bit of work for this one. Anything that requires preparing images is more time-consuming. While the actual keyframe animations are fairly straightforward, the associated styling required some experimentation to get everything coordinated. The background pan animation is intriguing, I may employ it in a regular webpage somewhere sometime. It is a new trick to add to my collection.

Source code

The source code is available in this github repo.

You can check out all of the animations of this series in this codepen collection.

Written by Rob O'Leary

Subscribe to web feed for the latest articles.

Testing experimental browser features on Linux - Is Linux supported?

Rob OLeary — Thu, 16 May 2024 11:30:00 +0000

I was exploring new HTML and CSS feaures yesterday, a new proposal called Invokers (InvokeEvent API) caught my attention. According to caniuse, invokers are available in the following browsers as an experimental feature:

Chrome - Available in Canary build only
Firefox - Can be enabled by setting dom.element.invokers.enabled to true
Safari - Can be enabled by setting InvokerAttributesEnabled to true

On my linux workstation, I looked to install Chrome Canary. I couldn't find it in an app repository. When I looked at the Chrome Canary website I saw that Linux is not supported. That's a shame!

I moved onto Firefox to enable the experimental setting. You can open the config settings by typing about:config in the omnibar. There I searched for the setting and enabled it.

I tried out an invoker demo (codepen) from Brecht De Ruyte's article on the topic, but it did not work! 😒 I tried the codepen in debug mode. Recently, Ubuntu has shifted to a snap as its default installation for Firefox.. Sometimes there can be gotchas around snaps. I installed Firefox through the Apt package to see if it made a difference, then tried again. No dice.

Since Safari is OS X only, bar some devilish tricks to force an installation on Linux, that puts the kibosh on my experimentation!

I don't know if I am just unlucky with my system configuration not to at least get Firefox to cooperate. It is sad that Linux is not given the same level of support as other Operating Systems in this regard.

Written by Rob O'Leary

Subscribe to web feed for the latest articles.

How to create a slick CSS animation from Cocktail

Rob OLeary — Wed, 24 Apr 2024 13:56:37 +0000

Let's jump to the 80's and create an animation with a retro feel. Cocktail!

Cocktail is a romantic comedy-drama made in 1988. If you have not heard of it, the most notably thing is that it stars a young Tom Cruise. He plays a New York City business student, who takes up bartending in order to make ends meet. Hijinks and bad fashion ensue.

TLDR

Here is the finished animation.

About the title sequence

The opening title sequence features neon text. Each title flickers on and off reminsicent of a neon sign. The text is ebullient with bright, saturated colours. The palette is blue, pink, and turquoise that was so prominent in the 80's. It is backed a trendy rock track by Starship.

You can watch the full title sequence on YouTube.

The title card for Cocktail

The title card looks like the sign for a bar. The text is in blue and it is surrounded by a pink ring. Looking at it through today's lens, it looks like a subpar design! I will resist reworking anything!

The font used is hard to pinpoint. The closest I could find is Gillies Gothic Light. The cursive style is similar. However, it does not have many of the serifs that join adjacent letters and the flourishes that give a more nuanced perception of a neon sign. I will stick with this font and not edit the gylphs to mirror the original.

My recreation of the title card for Cocktail using the Gillies Gothic Light font.

The animation

A neon effect is created with a shadow with a blur radius. For the text, we use the text-shadow property. When I was a CSS grasshopper, I thought that a single shadow with a large blur radius would suffice:

h1 {
  text-shadow: 0 0 30px blue;

  /* other styles */
}

Alas, it looks quite faint..

What you need to do is stack multiple shadows with larger and larger blur radii as below:

h1 {
  text-shadow: 0 0 5px blue, 0 0 10px blue, 
    0 0 15px blue, 0 0 20px blue, 
    0 0 25px blue, 0 0 30px blue;

  /* other styles */
}

To animate a text-shadow, we can set the aforementioned text-shadow in the to block of a @keyframes. We do not set any initial state. The browser does the work to interpolate the values for each of the shadows.

h1 {
  animation: flicker 2s infinite ease-in-out;
}

@keyframes flicker{
  to {
    text-shadow: 0 0 5px blue, 0 0 10px blue, 0 0 15px blue, 0 0 20px blue, 0 0 25px blue, 0 0 30px blue;
  }
}

I created the pink ring using the ::before pseudo-element. We cannot use text-shadow on it because there is no text!

h1::before {
  content: "";

  border-radius: 50%;
  width: 70%;
}

To create a shadow for the pink ring, we use the filter property with the drop-shadow() function. We do not use box-shadow because it will apply the shadow to the element's box which is a rectangle, thus ignores the shape of the element.

h1::before {
  filter: drop-shadow(0 0 0 hsla(300, 97%, 60%))
    drop-shadow(0 0 0 hsla(300, 97%, 60%))
    drop-shadow(0 0 0 hsla(300, 97%, 60%));
}

To animate the filter, we can do similar to what we did with text-shadow. This is what it looks like:

h1::before {
  animation: flicker-ring 2s infinite ease-in-out;
}

@keyframes flicker-ring {
  to {
    filter: drop-shadow(0 0 10px hsla(300, 97%, 60%))
      drop-shadow(0 0 20px hsla(300, 97%, 60%))
      drop-shadow(0 0 30px hsla(300, 97%, 60%));
  }
}

That is the core of the neon effect of the title card animation. I also animated opacity in the final animation to create a staged reveal before lighting up the title.

The final part of the animation is that the title card fades out. I think it is better to use 2 separate animations to get the desired result rather than to squash everything into a single keyframes. Since the title remains in its "lit" state for a couple of seconds, we can use an animation-delay to control this duration in the second animation.

To recap, the first animation reveals and lights up the title, the second animation leaves the "lit" state linger before it unlights and fades out the title. Here is the CSS for the animations for the ring:

h1::before {
  animation-name: on-ring, off-ring;
  animation-duration: var(--animation-duration), var(--animation-duration);
  animation-delay: 0s, var(--delay-duration);
  animation-timing-function: ease-in, ease-out;
  animation-fill-mode: forwards, forwards;
  animation-iteration-count: 1, 1;
}

@keyframes on-ring {
  to {
    filter: drop-shadow(0 0 10px var(--ring-glow-color))
      drop-shadow(0 0 20px var(--ring-glow-color))
      drop-shadow(0 0 30px var(--ring-glow-color))
      drop-shadow(0 0 30px var(--ring-glow-color-outer));
  }
}

@keyframes off-ring {
  to {
    filter: none;
  }
}

Notice that we use filter: none; to animate out the shadows for the ring!

That's it!

Written by Rob O'Leary

Subscribe to web feed for the latest articles.

How to create a slick CSS animation from Jackie Brown

Rob OLeary — Fri, 19 Apr 2024 13:36:56 +0000

Jackie Brown is an American crime film that pays homage to 1970s blaxploitation films. The title sequence is simple but has some 70's flair. Let's recreate the reveal animation of the title card.

TLDR

Here is the finished animation.

About the title sequence

The opening title sequence for Jackie Brown is an introductory scene with the titles overlaid. It introduces us to the titular character while she is making her through an airport to board a flight. It is quite hypnotic seeing Jackie standing on a travelator (moving walkway) with a mosiac tile wall passing in the background. The framing and placement of the titles is very well done.

Here is a short excerpt of the title sequence where the title of the movie is revealed:

You can view the full sequence at: https://www.youtube.com/watch?v=ivKGY-zAa1g.

The original font is probably ITC Tiffany Heavy. This has a commerical license, so I have not used it here. I used a free alternative called VI Vong Vang. It has similarities but is missing some of the elongated serifs and some glyphs are more condensed. It is good enough to fufil my brief. You can appreciate the differences in the figure 1.0 below.

Figure 1.0 - Comparsion of the original font used (top) with VI Vong Vang (bottom). VI Vong Vang is missing some of the elongated serifs and some glyphs are more condensed.

This is a good example of why you would pay for a typeface!

The reveal animation

There are a couple of considerations for the reveal animation:

The reveal animation has a slightly tapered end to create a vintage film feel. We want to have some partial transparency in the animation to give this impression.
It has thick shadows, so we need to ensure that these are not truncated by the animation. We need to compensate for that space.

The effect can be created by a mask as it allows partial transparency. We can use a linear gradient as the mask image to show a portion of the title at a time. The portion of the title we want to show, we use black in that portion of the gradient. The portion we want hidden, we have as transparent in the gradient.

For example, this linear gradient is 30% transparent and 70% black.

div {
    background-image: linear-gradient(to right, 
    transparent 0% 30%, 
    black 30% 100%);

    border: 2px dotted white;
}

If we apply the same gradient as a mask to the title with the mask-image, the initial 30% of the title is hidden.

.title{
    mask-image: linear-gradient(to right, 
    transparent 0% 30%, 
    black 30% 100%);
}

To animate it, we want to move the mask across the title using mask-position.

I found the easiest approach was to create a mask that is twice the width of the title. I made one half of the gradient transparent to completely hide the title, and the other half as mostly black to show the title. The intial position of the mask is to place the transparent half over the title.

This is the key CSS:

.title {
    mask-image: linear-gradient(
    to right,
    black 0% 50%,
    rgb(0 0 0 / 10%) 50%,
    transparent 51%,
    rgb(0 0 0 / 30%) 51.5%,
    transparent 51.5% 100%
  );
  mask-position: 100%;
  mask-size: 200% 100%;

  animation: reveal 1.5s;
  animation-fill-mode: forwards;
  animation-iteration-count: 1;
}

@keyframes reveal {
  100% {
    mask-position: 0%;
  }
}

I had to add some inline padding to the title to ensure that the mask did not truncate the edges of the title.

.title{
    padding: 0 1%;
}

Written by Rob O'Leary

Subscribe to RSS feed for the latest articles.

Eleventy - Create a global production flag

Rob OLeary — Mon, 19 Feb 2024 11:00:00 +0000

A production flag enables you to run activities in dev or production such as minifying assets, showing draft posts, etc. There isn't a built-in flag or function that comes with eleventy (11ty) specifically for this. However we have this info at our fingertips.

What is the simplest way to add a production flag to our eleventy project?

Make it global

I think the best choice is to put the functionality in a global data file. This makes the flag available in every template. You can use in your eleventy config and other JavaScript files if you require the data file. Other methods often led to some duplication.

A handier way of doing things ;-)

By default, global data files are located in the _data folder. I will create a JavaScript file called production.js in that folder to create a global production variable.

Code for the global `production` flag

Node.js exposes environment variables through process.env. Eleventy supplies its own environment variables to process.env also.

Since version 2.0, eleventy has made a process.env.ELEVENTY_RUN_MODE variable available. It has a value of build, serve, or watch. We can use this variable to make our production flag. The build value equates to our production mode since we only build when we deploy our project to production.

In our package.json, we can add npm scripts for running dev and production modes. The "build" script is our production mode -- this is what is run when we deploy our eleventy website to production.

{
  "name": "eleventy-production-flag",
    "scripts": {
    "dev": "eleventy --serve --incremental",
    "build": "eleventy",
  },
    "dependencies": {
        "@11ty/eleventy": "^2.0.1",
    }
}

I will add the functionality to _data/production.js. Its sole mission is to return a boolean value -- true if it is running in production mode, otherwise false. I will use an IIFE (Immediately Invoked Function Expression) that returns the boolean value.

// _data/production.js
module.exports = (function () {
  return process.env.ELEVENTY_RUN_MODE === "build";
})();

Now, you can now use the production variable throughout your project!

The nice thing about this methodology is that it is totally portable -- it works across all operating systems, and you don't need to set any environment variable yourself anywhere, anytime.

Use `production` in layouts and includes

You can use the production variable in layouts and includes. You don't need to do anything else thanks to the data cascade! 🥰

For example, we could have a different title on pages when you are running in dev versus production.

This can help when you are working on your website and occasionally checking deployments in the browser. It may prevent you mistaking a tab of the dev website for a tab of the production website. This is all the code you need in your head.njk include:

<!-- head.njk -->
<head>
    {% if production %}
        <title>{{ title}}</title>
    {% else %}
        <title>DEV - {{ title}}</title>
    {% endif %}

    <!-- other stuff -->
</head>

I do a variation on this theme with favicons for my own website. I have a bright green square favicon in dev mode to catch my eye, whereas production mode it is my actual favicon.

Use `production` in the eleventy config

You can use the production variable in your eleventy config but you must require the file.

For example, you can use it to exclude some files from the build. Here I am excluding my draft posts from the build.

// eleventy.config.js
const production = require("./_data/production");

module.exports = function (config) {

  if (production) {
    // e.g. exclude draft files
    config.ignores.add("./src/drafts/*.md");
  }
};

If you split your eleventy config into multiple files, you can do the exact same thing in each of those files and it will work the same way.

Source code

The source code is available in this GitHub repo.

You will find the project in the production-flag subfolder.

Did you enjoy this tutorial? If you did, could you give the repo a star to let me know please? 🌟🫶

Written by Rob O'Leary

Subscribe to web feed for the latest articles.

VS Code - Fix a task automation issue - `The terminal process failed to launch (exit code: 127)`

Rob OLeary — Thu, 18 Jan 2024 15:58:10 +0000

I like to run a web server automatically whenever I open a web project in VS Code. I use VS Code tasks to do this. Suddenly, this has stopped working, without rhyme or reason! 😓

I was greeted with the following error in the integrated terminal:

-> Executing task: pnpm dev

zsh:1: command not found: pnpm

The terminal process "/usr/bin/zsh '-c', 'pnpm dev'" failed to launch (exit code: 127).
Press any key to close the terminal

Nice to meet you exit code 127! Let's get to know each other! 🤗

The source of the issue

If you are not familiar with tasks in VS Code, check out this post that covers this very use case.

The task is running the (p)npm script called "dev". You can see the tasks.json file below.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Start server on startup",
      "type": "shell",
      "command": "pnpm dev",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      },
      "runOptions": { "runOn": "folderOpen" }
    }
  ]
}

The "dev" script is running the eleventy server in dev mode. The details of the script are not important for this discussion, but to round out the background here is an abbreviated version of my package.json:

{
  "name": "some-eleventy-website",
  "scripts": {
    "dev": "eleventy --serve --incremental --quiet",
  }
}

If I open a new integrated terminal and run pnpm dev, it runs the command successfully! It looks like it is specific to tasks.

The problem is that tasks are executed with Zsh using /bin/zsh -c, which starts a non-login, non-interactive session. This means that ~/.zshrc and ~/.zprofile are not sourced by Zsh. In my case, this means that I can't run the necessary local npm packages in a task. The solution should be to have tasks run in an interative shell session. How do we do that?

The fix

To start an interative Zsh shell session we want to pass the i flag to Zsh. After some digging, I found that there is a task/debug profile setting that let's you specify the environment for tasks. The setting has a version for each platform (windows/linux/osx) in the form of terminal.integrated.automationProfile.<platform>. For example, it would be terminal.integrated.automationProfile.linux for linux.

The fix for my linux setup was to add the following to the settings.json:

"terminal.integrated.automationProfile.linux": {
    "path": "/usr/bin/zsh",
    "args": ["-i"]
}

VS Code - Sticky code sections for improved contextual browsing (sticky scroll)

Rob OLeary — Mon, 20 Nov 2023 14:00:31 +0000

We read more code than we write. It is worthwhile considering if you have VS Code optimized for reading code. A telltale sign that things are subpar is if you find yourself scrolling up and down to re-establish the context of the code you are examining, absentmindedness excepted! Where am I again? 😵‍💫

One impactful aid is sticky headings that outline the scope of your position in a file. Let's see if it makes a difference!

First, let's take a quick look at what aids VS Code provides for establishing your current context.

Establishing your current context in VS Code

VS Code provides a number of visual aids to communicate where you are and what scope you are operating in:

The current file you have opened has the file name on the editor tab and in the titlebar,
The minimap shows your position in the current file in a floating graphical map,
The Explorer pane in the sidebar shows you the filetree of your workspace with your current file highlighted,
There are coloured brackets pairs and colored guidelines that outline the extent of scopes,
You can have breadcrumbs (breadcrumbs.enabled setting) that outline the scope of your position within the current file.

The floating minimap (righthand side) in VS Code shows your position in the file.

The bit for me that is not done well is having an overview of my scope within a file - what is the scope of the code I am currently examining? I find that breadcrumbs are crumby (pardon the pun) for recognizing the current scope in some languages. The breadcrumb trail becomes too long and text gets truncated.

The sticky setting

There is a nice setting called editor.stickyScroll.enabled that pins lines to the top of a file to give an overview of the current scope. Let's browse a HTML file with the setting enabled and see how it works. As you scroll down, every unterminated element has the line with its opening tag pinned as a sticky heading:

This displays your current context in an easy to digest way. You will really appreciate it when you have messy HTML files!

Here is what it looks for a JavaScript file within a fetch closure:

You can see 2 function definitions are stuck as the top 2 lines. As you scroll down whenever there is a nested scope such as a loop, it's declaration line will become stuck also. There are some exceptions, I noticed for JavaScript a plain old for loop does not stick, but a forEach() does!

To get this behaviour for all languages, you can add the following to your settings.json:



  "editor.stickyScroll.enabled": true,

So far, I like to have this in every language I use. If you don't want it for a particular language, you can disable it using the multiple language-specific syntax. For example, the following disables sticky scrolling for HTML and XML:



  "[html][xml]": {
    "editor.stickyScroll.enabled": false,
  },

You can limit the number of sticky lines with the editor.stickyScroll.maxLineCount setting. The default value is 5.

The state of HTML

Rob OLeary — Wed, 01 Nov 2023 10:33:57 +0000

HTML is the core technology of the web. Yet, it has changed very little in recent years. Is HTML complete? Is it neglected? What is the state of HTML?

What is the state of HTML?

My takes...

How is HTML used?

How to make a webpage, a summary: Take the HTML and fold it into the JavaScript

People don't write HTML in a HTML file very often these days. They write HTML embedded in something else - a template language such as nunjucks, or in a web component (mostly React).
For producing content, a lot of people write in markdown.
For interactive content, some people prefer the authoring experience of markdown plus their favourite UI framework. MDX is probably most popular variant of that.
In some respects, HTML has become more of an output format like PDF.

The medium

As a document-oriented medium, HTML has covered all of the bases for a long time. Dealing with text and multimedia content has been in the language since HTML 5 for the most part. That was 2008.
As an application-oriented medium, serving dynamic content as HTML in the client-server model is well served by server-side languages. People refer to this as Multi-Page Apps (MPAs) now. Quoting Jason Miller's application holotypes, content websites and storefronts are well for catered here. The difficulty arises when you want a richer interactive experience - a desktop-like app in the browser.
There are incongruities with what HTML offers and what is desirable for demanding applications. There is a desire to make granular changes to a webpage without requesting an entire HTML file from the server. A webpage is a HTML document, that is the unit of currency in the client-server world. HTTP is a stateless protocol, meaning that the server does not keep any data (state) between two requests. Therefore every page request can be like a reset. These are the major hurdles for a desktop-like experience over a network using HTTP and HTML. This has led to the development of Single-Page Apps (SPAs) and various hybrid approaches, usually where HTML is generated client-side from data.

Building user interfaces

People hands down reach for UI frameworks. Native web components were in the doldrums for some time. People may have their own component libraries or use UI kits.
There are deficiencies for building user interfaces. Some UI controls (input element and others like select) are hard to customize their style and behaviour. Not many UI controls have pseudo-elements that can be referenced in CSS. People make their own custom UI controls often.
There is interest in improving the state of the UI control elements but it hasn't yieled any results yet as far as I know. The Open UI group are advocating for adopting an industry standard definition of UI on the web. They did get an experimental input control called selectmenu added to Chrome recently, it is proposed as a replacement for the select element. They have proposals for other UI elements too.

Evolution of HTML

There have been some but not many changes to HTML in the last 2 to 3 years. The changes I am aware of are: the dialog element became evergreen, the search element was added, the inert attribute was added, lazy loading of images and iframes through the loading attribute has gotten wider support, and declarative shadow DOM has been implemented in some browsers.
There does not seem to be an interest in augmenting HTML to send and retrieve data at a more granular level than a file. The HTMX library is an example of what this could look like. It gives you access to AJAX, CSS transitions, web sockets, and server-sent events directly in HTML using attributes. Other project like Hotwire (Ruby) offer a similar approach where HTML fragments are requested to partially update a web page.
People are still a bit confused about the versioning of HTML since it moved from a number such as HTML 4.01 to a living standard i.e. constant evolution.

Handling data that is bound to HTML

Nowadays people use the form element far less for sending data to a server. Having an independent backend and frontend (split architecture) became more prominent with the advent of AJAX (Asynchronous JavaScript and XML). Now the fetch API or a similar library is used to retrieve data from a REST or GRAPHQL endpoint. The frontend is binding this data to HTML.
Static-site generators have become more sophisticated at fetching data from different sources to generate HTML at build time.
Application frameworks based on UI frameworks like Next (React) and Nuxt (Vue) provide data fetching as part of their featureset usually the code sits alongside your components. Most of the application frameworks tend to spit out a SPA, but some offer other "modes" such as a static site generation. Rich Harris calls this hybrid modality as Transitional Apps (TAs I guess) where you can opt into a mode for a component that will determine where and when your HTML is generated: client, server, or prerendered. He is trying to implement this concept in SvelteKit.
The trend now is to shifting towards a broad notion of server components. The concept is to have the same web component authoring experience but do it closer to the data on the server. The server returns mostly HTML rather than data and JavaScript. Frameworks like Astro are calling this content-first websites, where pre-rendering HTML and doing things server-side is the default. Astro allows you to bring your own UI framework and handles transformation. React is the first UI framework to formalize a standard (React Server Components) for this concept that application frameworks can implement. It is early days for it.
Server-side languages are still doing their thing. The default is to serve HTML. This is considered boring tech now. A tonne of the web still lives on the LAMP stack. You can build a server-side web application in almost any language now.

Education

I don't have much insight on how well HTML is taught in general now. From what I gather, there is a tendency of teaching just enough HTML and CSS to get to building things with JavaScript. It is left up to the student to cover things in more depth. It does appear some courses put more emphasis on accessibility now, which is a step forward.

Perception of HTML

Join us on the interweb - Hypertext is like jumping to another galaxy

Maybe, the last time there was excitement about HTML was when HTML 5 was shipped. Remember the website html5rocks.com?
There is a perception by some that there is not much to HTML. You can learn it quickly.
The industry surveys run by devographics on frontend technology started with the State of JavaScript survey in 2016. Subsequently annual surveys were added for CSS in 2019, and HTML in 2023. It demonstrates the relative priority given to the frontend technologies. These surveys are used as an input to the Interop initiative that is used to priortise improvement of browser features, so these surveys carry some weight.
Some people don't see HTML as a programming language, some do. It's not a productive debate in my opinion.

Defining moments

When you look back to try to understand where we are, it is hard to extrapolate the reasons why this or that happened. I would say that probably the inability to build to a webpage composed from multiple HTML files was the biggest spur for change. It is not practical to duplicate common fragments such as the website navigation across many HTML files. In the early days, people had some sort of HTML concatenation happening on a server or in a build step. There was technologies like Common Gateway Interface that enabled running scripts. Microsoft developed their server-side language Active Server Pages to be able to write dynamic webpages (gasp). None of it was particularly pretty initially. It eventually led to the rise of PHP and WordPress on the web, which provided a better experience of creating HTML from data server-side.

The web platform's proposal to resolve some of this in HTML was called HTML includes or something similar. It never happened. I guess the route was to permit building custom elements (native web components) in HTML instead. Native web components had a very rocky inception and did not offer a viable alternative to UI frameworks. You can read the article A Criticism of Web Components to get a background on the shortcomings. The platform was too stagnant in this area for too long and the solutions came from elsewhere.

I believe that native web components are more mature now and are a viable option. I am not speaking from experience. Dave Rupert has advocated for them, he writes about them in his article and talk titled HTML with Superpowers. Superpowers are welcome! In any case, it will take considerable time before there is a significant shift to native web components. As much as you may want to just use the platform, there are challenges to overcome.

The desire to have every type of application on the web with a desktop-like experience led to divergent architectures such as SPAs. The crux was atomic changes to a webpage and the perservation of appplication state. Perhaps a different path could have been made if HTML and related technologies were augmented to accomodate a wider range of applications with less reliance on JavaScript. At the moment, we are slimming down some of the fat clients that have become prevalent to reach a better compromise.

Reviewing survey questions from 2023 State of HTML Survey

The inaugural State of HTML survey was done recently. The arc of the survey seems to be that it is trying to ascertain what parts of HTML you know and use, and what parts are difficult to use. It is quite comprehensive, there are over 100 questions. The questions reiterated to me that there are always some tidbits about HTML that you do not know! There are some things that I don't use, and some things that I may never use!

Some things I never heard of:

<input type="file" accept="video/*" capture> - Captures input from the user’s camera. That's an interesting one!
controlslist attribute - Prevent certain controls from appearing in the toolbar of a media element e.g. video. Nice to have the option but did not reach for it before.
input.showPicker() - Programmatically opening the picker of form controls that have one (color pickers, date inputs etc).
contenteditable="plaintext-only" - Permits editing of the element's raw text, but not rich text formatting. I was aware of the attribute but not the value. Cool distinction but I'd always question if you should use this in the first place!

Some things I heard of but have not used:

<datalist> provides a method of providing a list of presets for a user to select in a form control, while still allowing custom options. Kind of helps with autocompletion. I never remember this one because it is not build into input!!
autocomplete attribute

New things I heard of:

dialog, search elements.
inert attribute
Popover API

Regular pain points:

Styling input and select elements.
Disclosure widgets - why can't I just use details? I need to look up the caveats.
Adding width and height to images to prevent Cumulative Layout Shift. Need to configure a tool to take care of this.
There is a bit of a pardigm clash with responsive syntax for images that is based on viewport size and container queries that is based on the element size. I don't know how to tackle this in a consistent way yet.

HTML-y things that I haven't really used but would like to use more at some point in time:

Native web components
Some Progressive Web App APIs - the ability to build a proper web app with core technologies and publish to an app store is a dream!

Conclusion

Web development is weird. Once all you had was HTML. It was everything on the web. Now, HTML has become more of an final, output format like PDF rather than something you write a webpage in! It is like a garnish on a dish, the most visible bit on top that you consider last and regard least! Yet, still a webpage is nothing without HTML. It is a bit of paradox.

I think there are improvements that can be made to HTML that will make the web better. HTML is not complete! The first port of call for me would be to improve the experience making user interfaces with HTML. Make UI controls (select et al) easier to style and add behaviour to. The Open UI group are advocating for adopting an industry standard definition of UI on the web. Let's listen to them. There is some movement on this front with the experimental selectmenu element in Chrome. Let's crank that up!

I would like to see HTML evolve further. A paradigm to offer a partial update to a webpage is needed. There should be a HTML-y way to do the islands and hydration stuff that is sweeping through JavaScript. The HTMX library offers an example of what this could look like using attributes and leveraging existing protocols such as HTTP and websockets.

I will be interested to see the results of the State of HTML survey.

How do you market software?

Rob OLeary — Mon, 14 Aug 2023 09:10:23 +0000

How do you market new software? Do you just splash it across social media and other tech platforms? Talk about it at conferences and on podcasts? Pay for advertising spots and sponsored posts?

Mostly it seems people try to put their software in front of as many eyes and ears as possible. Is there something significant that will count in the longrun?

I like Adam Whathan's observation about Tailwind's documentation:

Some of the most important marketing we do I think though is our documentation. Making Tailwind as easy to learn and easy to be as successful with as possible is what makes the entire business able to work. Any effort I put into that I expect to have a much higher pay-off than paying for a Facebook ad for Tailwind UI or something, but it's absolutely marketing, and I think that's probably part of why it doesn't look like we are doing a lot of marketing from the outside. I try to put our marketing effort into things with a long-term pay-off, which is why we don't even do things like Black Friday sales anymore or anything either.

The docs are often the first impression that people have of your product. Great docs are one of the best things you can do to win people over. If someone can recommend your product by simply saying "just visit the website - its got everything you need to know", that's one of the best endorsements you can get.

I recall a member of the Vue core team referring to their methodology as "documentation-driven development" when speaking on a podcast. The thesis was that if you can't explain a concept clearly and succinctly to others (through the docs), then maybe the code needs more work! It is similar to rubberducking, but for development. I think getting feedback like that early can really benefit the product. It is amazing how often we underestimate how hard it can be to explain something to an outsider who has not been involved in the project, you lose objectivity!

Anything that gets you closer to making something people find intuitive and easy to pick up will put you on the road to success.

Is Lighthouse a misleading performance tool?

Rob OLeary — Fri, 07 Jul 2023 10:00:00 +0000

Google calls Lighthouse "an open-source, automated tool for improving the quality of web pages". It is not a performance tool per se, but a prominent feature is giving feedback on a webpage's performance. It is a big challenge to get a top performance score for mobile in Lighthouse. If you have tried to attain a top score in Lighthouse -- it may have made you doubt yourself, the tool, or both! Let's explore Lighthouse to see why this is.

Is Lighthouse misleading, or is it a misunderstanding?

Issue 1 - The scoring scale is not linear

You may think that the performance score is linear where a score of 100 is 10% better than a score of 90, but that is not the case. Actually the score follows a curved distribution, here is the score curve of the Time to Interactive (TTI) metric:

Google mentions this in their docs when they discuss how scores are color coded:

To provide a good user experience, sites should strive to have a good score (90-100). A "perfect" score of 100 is extremely challenging to achieve and not expected. For example, taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94.

This characteristic of the calculation of the performance score means that the effort you put in to improve your score will vary depending on where you are on the curve. To make an analogy, it is like a runner putting in equal effort throughout a race:

Running downhill: the runner will run faster;
On the flat: the runner will run at their regular pace;
Uphill: the runner will run slower.

Perhaps, you did not expect this from a scoring system from zero to 100. I didn't! After all the word percent means "one part in a hundred". This misunderstanding could have been mitigated if a different range or distribution was chosen. Maybe, it would trip less people up if they showed the score as a point on the curve for each metric?

You can dig into the details of the scoring algorithm to understand it more deeply.

Issue 2 - Scores can vary a lot

If you run Lighthouse on the same website using the same computer on the same network multiple times, you will get variable results. This feels weird at first. I'm repeating the exact same thing and getting a different result? Is this a bug or a warped reality?

Google says the following on score variability:

A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it's usually because of changes in underlying conditions. Common problems include:

A/B tests or changes in ads being served

Internet traffic routing changes

Testing on different devices, such as a high-performance desktop and a low-performance laptop

Browser extensions that inject JavaScript and add/modify network requests

Antivirus software

It is not due to Lighthouse? 🤔 Are we are trying to handcuff lightning here? 😏

How variable can it be?

Take testing on different hardware. The swing can be dramatic. Zach Leatherman discussed this in an article -- The Art of Deception, Lighthouse Score Edition -- running Lighthouse on a Macbook (2012) versus a MacBook Air (M1, 2020) resulted in a 30 point swing! That's a lot.

It appears that you can mitigate the impact of hardware by running Lighthouse through PageSpeed Insights (PSI), Google's web-based user experience tool. I guess this hits a particular set of servers consistently.

Google gives a full list of the technical factors for these variances if you want to get into the nitty gritty.

The advice in Lighthouse's GitHub repo to reduce variability is to "run Lighthouse multiple times and beware of variability before drawing conclusions about a performance-impacting change". Why not build this behaviour into Lighthouse to reduce variability?

WebPageTest is a rival web performance tool and their default behaviour is to give a median performance score based on 3 runs. The WebPageTest team have been critical of the consistency of Lighthouse results. It is possible to run Lighthouse through WebPageTest, and they claim they can provide more consistent results from Lighthouse because they provide a more consistent test environment.

While some variability between tests is to be expected, by providing a consistent test environment for all Lighthouse runs, WebPageTest helps to minimize that variability and provide a realistic and repeatable point of comparison.

They point to Lighthouse's use of simulated throttling as one source of variability that could be mitigated.

By default, Lighthouse uses simulated throttling: the test gets run without throttling, and then Lighthouse simulates what a throttled load might look like based on the unthrottled results.

WebPageTest, on the other hand, uses packet-level throttling for all tests, including Lighthouse tests run through WebPageTest. Because packet-level throttling enables network shaping at the packet-level, it's a far more accurate modeling of real network-conditions (there's a fascinating study by the Lighthouse team about throttling accuracy if you want to wade into the weeds on the topic).

Issue 3 - The vast majority of websites are ranked as not good

Let's go back to 2020, this was when Google made a big change regarding their performance rating -- they introduced the Core Web Vitals. I want to discuss this timeframe because it was the last point where there is clear comparable data between the performance metric set (5 metrics) and the Core Web Vitals (3 metrics). The Core Web Vitals is a subset of the performance metric set.

The Core Web Vitals was introduced as an effort to simplify things. To quote Google:

Site owners should not have to be performance gurus in order to understand the quality of experience they are delivering to their users. The Web Vitals initiative aims to simplify the landscape, and help sites focus on the metrics that matter most, the Core Web Vitals.

The Web Almanac 2020 edition demonstrated in their performance review of the web that Lighthouse reported 0.7% of websites having a mobile performance score of 100, and 5.7% of websites were in the good category (90-100). Was web performance really that bad? Or is the bar too high?

I used the same dataset as the Web Alamanac to extrapolate how many websites fell into the "good" catgegory for that period. The data can be found in this Google spreadsheet.

I was trying to understand how Google picks the good category thresholds and this is their clearest explanation, specifically for the Largest Contentful Paint (LCP) metric:

Based on real website data, top-performing sites render LCP in about 1,220ms, so that metric value is mapped to a score of 99.

Going a bit deeper, the Lighthouse scoring curve model uses HTTPArchive data to determine two control points that then set the shape of a log-normal curve. The 25th percentile of HTTPArchive data becomes a score of 50 (the median control point), and the 8th percentile becomes a score of 90 (the good/green control point).

Does that mean that the upper 8% of the data represents a score of 90 and above? I don't get their explanation to be honest! 😕 Although it sounds about right based on my previous analysis from the Web Almanac.

Barry Pollard did some analysis of Lighthouse scores across the web by querying data on the HTTP Archive in his article, What do Lighthouse Scores look like across the web?, and the results are similiar. He said the following about top level scores:

[..] 90% of sites score 80 or less on Performance or, to put it another way, only 10% of sites score higher than 80 in the Performance category.

It will always be that only a small portion of websites achieve a "good" performance score because it is the upper 8th percentile that make up this category. If web peformance dramatically improved across millions of websites overnight, the bar will be raised and even more is required to get into the "good" category.

Based on the same data (the Chrome User Experience Report data that is available through the HTTP archive) for the same approximate period (August to October 2020), 22.3% of pages passed all 3 Core Web Vital metrics with a "good" score. More websites pass the Core Web Vitals than get a "good" performance score in Lighthouse.

In the subsequent years, refinements to the performance scoring have been made. The latest version of Lighthouse is 10. Five of the same metrics are used in the scoring since version 6, the thresholds and weights have been tweaked. A new metric called Interaction to Next Paint (INP) has been introduced recently and will replace First Input Delay (FID) in March 2024 as a Core Web Vital metric.

What I find strange is that Lighthouse in Chrome's devtools does not mention Core Web Vitals at all. It still gives the performance score on 5 metrics. Why give people the more complex and more challenging set of metrics then?

No mention of Core Web Vitals in results for Lighthouse in the browser devtools

For defining the thresholds, Google explains the science behind the thresholds related to human perception thresholds and relevant HCI research. The thresholds are based on how we percieve things, but how achievable is that on the web? Google says the following in their article on defining thresholds:

To confirm that a threshold is achievable, we require that at least 10% of origins currently meet the "good" threshold. Additionally, to ensure that well-optimized sites are not misclassified due to variability in field data, we also verify that well-optimized content consistently meets the "good" threshold.

So with all the numbers mentioned, the minimum requirement by Google is that 10% of the web is classified as meeting the "good" performance threshold for the Core Web Vitals. That sounds like the Core Web Vitals are a bit more lenient than the overall performance set, but are still very challenging.

We can see figures for the Core Web Vitals for the last 3 plus years on HTTPArchive, the percentage of origins passing the Core Web Vitals for mobile has increased from 22.6% to 40.7%.

I would love to see the same graph for the overall performance score. My guess is that would be a lot lower.

Issue 4 - Is it field data or lab data?

It is important to understand the difference between lab data and field data. Lighthouse is a lab-based tool, also known as a synthetic tool.

Lab data is collected within a controlled environment with predefined device and network settings. Its main use is for debugging performance issues because it provides a reproducible testing and debugging environment. The downside is that lab data does not capture real-world bottlenecks well.

Field data is performance data collected from real page loads your users are experiencing in the wild. Tools that gather field data are often referred to as Real User Monitoring (RUM) tools. Field data captures true real-world user experience.PageSpeed Insights uses the Chrome User Experience Report (CrUX) dataset to augment lab data provided by Lighthouse for the same metrics. However, your page or origin may not be in the dataset because it is not publicly discoverable or there are not a large enough number of visitors in order to create a statistically significant dataset.

A good example of this dicothomy is to view a PSI report on web.dev, this is Google's blog that has a lot of information on Lighthouse. You can see the result of the very test I ran at this URL: https://pagespeed.web.dev/analysis/https-web-dev/hp4cd34d4i?form_factor=mobile.

Lighthouse reported a performance score of 96, but it failed the Core Web Vitals! At a glance, it can look like a mistake! How did that happen?

It is because PSI reports different figures for the LCP metric for the Core Web Vitals and the overall performance score (see yellow highlights in screenshot below)! The figures are different because PSI uses field data from the CrUX dataset for the Core Web Vitals (when it is available) in the first section, whereas lab data is used for the performance score in the second section.

You may miss this! Having 2 different metric sets using 2 different datasets side by side was confusing for me initially. Also, if you are focusing on the Core Web Vitals, there are 2 sets based on the testing method:

Lab testing in Lighthouse: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT).
Field testing in PageSpeed Insights: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), First Input Delay (FID).

Previously, the PSI report was more explicit about whether field data or lab data is being used the results shown. Here is an example screenshot of the PSI report from a few years ago:

I think that the updates to the UI look prettier but are less apparent.

You can read more about how think of tools in How To Think About Speed Tools by web.dev.

Issue 5 - Mobile or Desktop?

When people discuss and compare Lighthouse scores, often they take screenshots to keep a record. There is no indication in the UI if results are for mobile or desktop. The thresholds for mobile performance are higher. This is avenue for mistakes and misrepresentation.

Is this a Mobile or Desktop score?

There has been discussion about adding a visual indicator to make the mode more obvious, but it has not made it into Chrome devtools!

Issue 6 - People inevitably aim for near perfect scores

Inevitably, people aim to get a near perfect performance score. People take pride in what they do and want to point to something they made, and say "check out the performance of this". If you build a tool with high thresholds, then you put achieving a top score out of reach for some types of websites and web applications. There is no differentiation between a demanding web store like amazon, a web application like Google Docs, and a personal website.

To highlight this situation, there is a discussion thread, "Instruction to get score 100 on the mobile" on the Lighthouse GithHub repo:

I have used the lighthouse to monitor a website for the performance. However, it's really hard to get 100 score for the mobile. I only can get the score 100 for the mobile with the site that contains only a static text without css, javascript.

I'm not sure if lighthouse team considers that the website contains only a static text is popular nowaday for the modern website.

Of course, the PWA is not standard today yet and even for the PWA, we must load for "full state" mode as well.

I was surprised by this a while back too. I approached rebuilding my personal website by starting with the simplest possible homepage. I had no images, quite a small stylesheet, and I think I used 3 web fonts. It did not get a "good" mobile score! I had to optimize these assets to climb into the 90's.

Another part of this is that when numbers are involved, it can led to a competitive element. Frameworks and libraries lean into this to promote the speed and performance of their offering. Eleventy has a leaderboard that uses a Lighthouse-based plugin called speedlify to rank websites.

Is Lighthouse suitable for comparing sites in this way? 🤨

Final thoughts

Measuring web performance is a difficult proposition. We are not making homogeneous web-based products in an uniform way. This makes it a challenge to define what is good performance for something on the web. Google has been active in defining what is good performance through its metrics and tools, and has a big say on the matter.

Google calls Lighthouse "an open-source, automated tool for improving the quality of web pages". It inspects a few different facets of a webpage in its audits such as: performance, SEO, and accessibility. It is not a performance auditing tool per se, but it has a big presence in that space because Google made it, put it into Chrome, and announced it that the Core Web Vitals metrics are a factor in their search ranking!

Lighthouse is primarily a lab-based tool that is used for performance debugging. It has some characteristics that are not apparent. The scoring calculation is byzantine, results can be very variable, and it is very difficult to get a "good" performance score for mobile. As I covered in this article, some of it can attributed to the need to understand web performance and Lighthouse fairly well, but in some ways Lighthouse is misleading.

Google says a perfect mobile performance score of 100 is "extremely challenging to achieve". Their approach to performance classification is a lot more stick than carrot. In late 2020, by Lighthouse's classification less than 6% of web origins were deemed to have attained "good" performance, whereas 22.3% passed the Core Web Vital metrics. The Core Web Vital is a more lenient set of metrics.

The Core Web Vitals has made more businesses pay attention to web performance. As the Web Almanac put it in 2022 performance review:

Google’s decision to make CWV [Core Web Vital] part of search ranking catapulted performance to the top of many companies’ roadmaps, especially in the SEO industry. Individual site owners are certainly working hard to improve their performance and played a major role in the CWV improvements over the last year, even if those individual efforts are much harder to spot at this scale.

The percentage of origins passing the Core Web Vitals for mobile at the time of writing is 40.7%.

The aim of the Web Vitals initiative was to simplify the performance landscape, it hasn't done that well in my opinion. There is a lack of clarity and focus. Your performance score is still based on the complete set of metrics. The complete metric set is shown in Chrome's devtools, which is where many people encounter Lighthouse for the first time.

The CWV metrics haven't been embraced fully anywhere really. PSI shows the CWV metrics first, but 3 more metrics sit right alongside them. It does not give a clear message to users - should you be passing CWV or getting a "good" performance score or both? And what is a realistic score for your particular type of application?

Score variability means that Lighthouse comes with caveats. Generally it is not a very reliable performance debugging tool. Since score variability is skewed by your machine's performance when it is run locally, it is probably not a good idea to run Lighthouse in the Chrome's devtools. It is better to use Lighthouse through WebPageTest where it does more to mitigate variability, or use other tools for debugging performance.

I would recommend using Lighthouse primarily to understand how Google classifies your website. The opportunities presented by the Lighthouse audit give you a rough guide to improve performance but take it with a dash of salt. Field data gives you a more realistic view of user experience and you should favour that for understanding the performance of your website.

You can subscribe to my RSS feed to get my latest articles.

AI and the open web

Rob OLeary — Mon, 03 Jul 2023 10:00:00 +0000

It seems that there is a growing protectionist trend where large platforms are restricting access to data more tightly. It has come to the forefront recently as large language models such as GPT used by ChatGPT have become a more mainstream success story. Platforms are concerned their data is being used to fuel the burgeoning industry and they are not being compensated. If it leads to more closed behaviour on the web, it will become a negative trend.

Protectionist trend - Reddit, now Twitter

In June, Reddit raised prices on their API. Reddit’s owners are planning to take the company public, and they are looking to boost revenue from the social news site before they do. Reddit founder and CEO Steve Huffman told The New York Times "The Reddit corpus of data is really valuable, but we don’t need to give all of that value to some of the largest companies in the world for free."

This has led to an ongoing strike with volunteer moderators that has caused mass disruption on the platform. Steve Huffman said that the business will not be backing down. He told The Associated Press, "Protest and dissent is important. The problem with this one is it’s not going to change anything because we made a business decision that we’re not negotiating on." It has reached an impasse.

Yesterday, Elon Musk announced that Twitter is putting a limit on how many posts you can read per day. This is what he said in a tweet:

To address extreme levels of data scraping & system manipulation, we’ve applied the following temporary limits:

Verified accounts are limited to reading 6000 posts/day

Unverified accounts to 600 posts/day

New unverified accounts to 300/day

Later, Musk tweeted that the limit had been raised to 10,000, 1,000, and 500 respectively.

"Several hundred organizations (maybe more) were scraping Twitter data extremely aggressively, to the point where it was affecting the real user experience," Musk said.

It sounds strange that there is this kind of scraping being done at scale. It is an inefficient way to gather that kind of data. Even if Twitter is worried that some companies are getting around paying for access to its API by scraping webpages, restricting usage for regular users seems like cutting off your nose to spite your face. Usually, businesses want to encourage people to use their service as much as possible, because that is how they make money!

How will it play out?

It is hard to tell how this will play out. It is a battle to monetize this new frontier. The data holders want a slice of the pie if they are a prime sources for language models to train models to interact in a more human-like fashion. It could be that this is being opportunistically used to increase prices for API access. Blame the bots! The truth is that it is hard to know what the reality is unless you are behind the scenes.

Users are suffering as they are put in the middle. The market for third-party apps shrinks and it can become untenable for some small businesses. That is bad for consumer choice.

Web standards need to adapt. At the moment, I guess AI bots are indexing pages like search engine bots based on the robots.txt file. Permission for using data for language models is not explicit as far as I know. You may have to explicitly block a bot to opt out. For example, OpenAI has published instructions for blocking its bot.

It is likely that regulation will be required in the long-term. The major players are large companies and they have a big advantage. It will depend on if they want to defend their high ground aggressively.

Final thoughts

Personally, I don't see this as an alarming thing. This is a familiar fight. It is just something that we need to figure out.

Open information and commerce have always been incongruent. This is a battle over information — who produces it, how you access it, and who gets paid for it. In Reddit's case, it is galling that their data is moderated by users for free and is being sold at a growing cost -- it will be an interesting test case to see how this side of the AI revolution evolves. It is important how this is settled because it will shape what the web will become.

We should try to perserve openness, it is a great strength of the web. There needs to be a viable commercial solution to satisfy business needs. If one is not found, we need to mitigate harm being done through regulation.

DEV Community: Rob OLeary

Eleventy - Is it time to upgrade to version 3?

How to upgrade

Upgrade issues

Error 1 - Tabs are prohibited in YAML frontmatter

Error 2 - Failed version check of Sass plugin

Error 3 - A peciular TemplateContentPrematureUseError error

What about converting your eleventy configuration to ESM?

Conclusion

How to create a slick CSS animation from Alien

TLDR

About the title sequence

The animation

Part 1 - The background pan animation

Part 2 - Credit reveal animation

Part 3 - The title reveal animation

Cutting up the letters into segments

Final thoughts

Source code

Testing experimental browser features on Linux - Is Linux supported?

How to create a slick CSS animation from Cocktail

TLDR

About the title sequence

The animation

How to create a slick CSS animation from Jackie Brown

TLDR

About the title sequence

The reveal animation

Eleventy - Create a global production flag

Make it global

Code for the global production flag

Use production in layouts and includes

Use production in the eleventy config

Source code

VS Code - Fix a task automation issue - `The terminal process failed to launch (exit code: 127)`

The source of the issue

The fix

VS Code - Sticky code sections for improved contextual browsing (sticky scroll)

Establishing your current context in VS Code

The sticky setting

The state of HTML

What is the state of HTML?

How is HTML used?

The medium

Building user interfaces

Evolution of HTML

Handling data that is bound to HTML

Education

Perception of HTML

Defining moments

Reviewing survey questions from 2023 State of HTML Survey

Conclusion

How do you market software?

Is Lighthouse a misleading performance tool?

Issue 1 - The scoring scale is not linear

Issue 2 - Scores can vary a lot

Issue 3 - The vast majority of websites are ranked as not good

Issue 4 - Is it field data or lab data?

Issue 5 - Mobile or Desktop?

Issue 6 - People inevitably aim for near perfect scores

Final thoughts

AI and the open web

Protectionist trend - Reddit, now Twitter

How will it play out?

Final thoughts

Error 3 - A peciular `TemplateContentPrematureUseError` error

Code for the global `production` flag

Use `production` in layouts and includes

Use `production` in the eleventy config