DEV Community: Stefan Judis

Web Weekly 171 — ::details-content goes baseline, the `closed-by` attribute, and `field-sizing: content`.

Stefan Judis — Tue, 21 Oct 2025 04:10:00 +0000

Guten Tag! Guten Tag! 👋

Do you know what core web vitals metrics work across browsers? Have you used the closed-by attribute? And is AI really saving time?

Turn on the Web Weekly tune and find some answers below. Enjoy!

Kate listens to "Dick Around" by Sparks and says:

"I'm not saying this is my work anthem, but every day, every day, every night, every night..."

Do you want to share your favorite song with the Web Weekly community? Hit reply; there are five more songs left in the queue.

Last week, I opened Web Weekly with CSS functions (@function) and how they can be used to create a custom --light-dark() function. I learned some things from the reactions.

The existing light-dark() function only works with color values. Why's that?

Bramus blogged about it back in 2023 and the answer is to ship something. The main idea that led to light-dark() was to have a flexible schemed-value() function.

Specifications are complicated and folks preferred to ship light-dark() over figuring out how to have a highly dynamic function which might have taken "a while". If you want to follow further conversations, here's a spec issue discussing how light-dark() could work for images.

But are there other ways to change non-color styles based on the current color scheme? Ana advocated for a boolean toggle trick.

To be honest, I'm not the biggest fan of these because they're unreadable in my opinion, but hey... use what works for you.

If you enjoy Web Weekly, share it with your friends and family.

🦋 Bluesky
🐘 Mastodon
💼 Linkedin

A quick "repost" really helps this indie newsletter out. Thank you! ❤️

Something that made me smile this week

I admire people that take the time and effort to create truly unique online portfolios. This post highlights 6 personal websites of which I really don't want to know how long it took to create them.

Stand out

No code

Are editor themes too "loud"?

I've been happily using the seti theme for years because it's colorful and bright. Niki argues that most themes out there highlight too much. And what should I say, I think he's right and I'll give another theme a try!

Calm your editor

`closed-by=any`

Adam argues that there aren't enough people talking about the closed-by attribute. And he's right!

closed-by is the declarative way to tell open dialogs when they should close. The property doesn't work in Safari yet, but you can bring in a short JS snippet.

Declare

When the virtual keyboard messes with your viewport

Maybe you know the problem, you're on your phone, want to edit some data, the virtual keyboard opens and whoops, important fixed-positioned elements are gone. Where did they go?

Bramus explained how the different viewports (yes, multiple!) are affected by the keyboard and how the fairly new interactive-widget meta element value can help.

Embrace the view(port)

`header` and `footer` elements change their roles

You're probably using header and footer elements to improve HTML semantics and accessibility, but do you know that the elements don't always get their initial ARIA roles assigned?

Give some structure

Wowza! Would you enjoy getting Web Weekly straight to your inbox?

The wonderful weird web – spurious correlations

I've got nothing but love for the person maintaining this site highlighting correlations that don't look "quite right".

Check the numbers

`field-sizing` works for `input` and `select` elements, too!

Here's a quick one: have you heard about the field-sizing property? The new prop allows form controls to grow depending on their content. I thought this will only be about textareas, but it works for input and select elements, too!

Grow!

25 CSS you should know

Here's Adam giving a whirlwind tour about the latest and greatest CSS features. It'll be well worth your time!

Watch the talk Check the slides

Is AI really saving time?

Theoretically, this post belongs in the "No code" section but Hidde phrased all my thoughts way better than I could, so that I want to highlight it. If you question AI time savings, you should read it!

Evaluate

More perf metrics in more browsers!

When Google started pushing the Core Web Vitals metrics, they were pretty much a Chromium-only thing. Which was a bummer, because then we couldn't measure the experience of people using other browsers.

The competition is slowly catching up though! Let me share some web vitals news:

Firefox 144 shipped interactionId as part of the PerformanceEventTiming so that you can now evaluate the INP metric
Safari TP 229 supports INP
Safari TP 230 supports LCP

If you now want to gather all these metrics across browsers, use Google's web-vitals library which should work for all browsers. Happy measuring!

Yet another CSS reset

Paweł joined the club of people blogging about their CSS reset preferences (I'm still flying without... 🫣). The post includes some good opinions and lots of links to go deeper!

Reset

Random MDN – `Object.freeze()`

From the unlimited MDN knowledge archive...

Did you know that you can freeze JavaScript objects? Now you do. 🫵

Freeze!

New on the baseline

Did you already celebrate that ::details-content went into the baseline with Firefox 143? If not, now's the time!

Spice up all these details

Three valuable projects to have a look at

bodadotsh/npm-security-best-practices – How to stay safe from NPM supply chain attacks.
lirantal/npq – Safely install npm packages by auditing them pre-install stage.
bgreenwell/doxx – Expose the contents of .docx files without leaving your terminal.

A new Tiny Helper

I must admit, this one is really cool! You can enter "Make Graph" put some data in and get some graphs out. I can totally see myself using this to create visualizations without code or Excel!

Graph it!

Find more single-purpose online tools on tiny-helpers.dev.

Thought of the week

You've probably noticed that I'm an RSS fan boy, so it's no surprise that Molly's post "Curate your own newspaper with RSS" was right down my alley.

Using RSS is a way to regain control over the information you read online.

Do you enjoy Web Weekly? | Did you learn something from this issue?

❤️ If so, join 25 other Web Weekly supporters and give back with a small monthly donation on Patreon or GitHub Sponsors.

This is all, friends!

Loved this email? Hated this email? I want to hear about it!

If you think something needs improvement or something sparked some joy, reply to this email because I want to know more!

And with that, take care of yourself - mentally, physically, and emotionally.

I'll see you next week! 👋

Header and footer elements lose their roles in sectioning content

Stefan Judis — Sun, 19 Oct 2025 22:00:00 +0000

Using proper ARIA landmark roles allows assistive technologies to navigate a page. You probably know about some common ones: main (main), header (banner), footer (contentinfo). But do you know that header and footer don't always get assigned their initial ARIA roles?

Here's an example:

<header>
  "Root" header
</header>
<main>
  <header>
    "Main" header
  </header>
  <footer>
    "Main" footer
  </footer>
</main>
<footer>
  "Root" footer
</footer>

This HTML snippet includes header and footer elements that are a) on the root level and b) included in a main element. If you check the browser's accessibility tools, these elements get different roles assigned.

The header element loses its banner role and depending on the browser gets generic or sectionheader assigned, which has an effect on assistive technologies. Here's Martin in his post "Page headings don't belong in the header":

The header would carry no semantic meaning, so screen reader users would be left wondering where the main page header landmark was.

You can find similar behavior, though not identical, with the footer element.

Footer elements receive varying roles from sectionfooter and generic.

If you look at the "ARIA in HTML" spec, you'll find some answers.

For the header element:

If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=banner. Otherwise, role=generic.

For the footer element

If not a descendant of an article, aside, main, nav or section element, or an element with role=article, complementary, main, navigation or region then role=contentinfo. Otherwise, role=generic.

But what if you can't change the document structure or really want to have the header element in a sectioning main? If you really must, you can get out the hammer and add a landmark role yourself.

<main>
  <header role="banner">
    "Main" header
  </header>
</main>

I'm not sure how I feel about this, though.

I've wondered why Chromium and Safari 26+ didn't follow the spec and didn't switch to the generic role. It turns out, lucky me published this post right in the middle of some work-in-progress ARIA spec changes:

sectionheader and sectionfooter are new roles being worked on. Chromium and Safari started to ship the new semantics already. Firefox still has to implement the new aria mappings.

Thanks to Manuel and Luke pointing me in the right direction.

Where does this lead us? You probably shouldn't rely on or use the new sectionheader and sectionfooter roles yet. Here's Luke from Igalia giving some advice:

Browser support needs to improve but AT also won't necessarily understand these roles yet.

It will take some time until browsers have caught up and then still screen readers need to implement the new roles, too. This won't happen until tomorrow.

But generally, whenever you use header or footer elements, make sure to double check the applied ARIA landmark roles and avoid placing the elements in sectioning content like the main element. Otherwise, you might not provide the accessibility benefits you're hoping for.

Creating Animated Accordions with the Details Element and Modern CSS

Stefan Judis — Mon, 10 Mar 2025 10:36:56 +0000

Accordions are everywhere these days. GitHub has them on their home page right now. Figma ships them, too. I've implemented so many custom accordions that I can't count them.

But I must say, today’s accordions are pretty fancy. Here's what you'll find on github.com.

The accordion opens and closes with a good-looking slide animation, and when you toggle the entries, the image on the right column reflects the currently open entry.

How does this work?

JavaScript toggles data attributes and classes, and the good old CSS grid 0fr to 1fr trick is used to open the details content with a slide transition.

What If I told you you can build the same thing using only HTML and modern CSS?

Check out this version that I built.

This example is built without any JavaScript. Without JS? Yep, there’s not a single script element.

Let me show you how to create these fancy accordions using details elements, the new interpolate-size and transition-behavior CSS properties, and the:has() selector.

Disclaimer: At the time of writing, some described CSS features are Chromium-only. However, all the features can be treated as progressive enhancement, and the accordion will still work for other browsers. The only thing missing will be the sliding animation.

Generating markup from your design

Whenever I want to sketch something like this quick 50/50 layout, I reach for Builder's Visual Copilot. Design something in Figma, import the design into Builder using the Figma plugin, and off you go.

After Builder generates the component source code, you can either copy and paste it into your editor or go the fancy route and automatically add your codified designs to your project with a single npx command.

You can even “talk” to your components, ask for improvements and refactorings, and export your designs to vanilla web HTML/CSS, React, Vue, and even Swift. It's pretty cool!

But let's get to our vanilla accordion code!

The base setup

After generating some juicy CSS, I cleaned things up a bit (AI ain't perfect yet) and ended up with the following HTML for our new accordion component.

<div class="accordion">
  <div class="detailsColumn">
    <details open>
      <summary>First entry</summary>
      <p>...<p>
    </details>
    <details>
      <summary>Second entry</summary>
      <p>...</p>
    </details>
    <details>
      <summary>Third entry</summary>
      <p>...</p>
    </details>
  </div>
  <div class="imagesColumn"></div>
</div>

The details elements allow us to show and hide content by clicking on the visible summary element. Additionally, the first element is already expanded by setting the open attribute.

Let's style the details elements and make them a real accordion that only allows one entry to be open!

Removing the `details` default styling

The details default styles are valuable for quick designs, but we aim for something more polished here. So, where are these triangle markers coming from?

The tiny triangles are defined in the user agent stylesheets. Unfortunately, Chromium/Firefox and Webkit render them in different ways.

Chromium/Firefox defines a display: list-item on the summary element. Similar to li element, these elements come with a stylable ::marker pseudo-element, which can also be adjusted using the list-style property.

To remove the triangles coming from list-style-type: disclosure-open, you can either declare list-style: none to remove all the ::marker elements or change the display property to anything but list-item to avoid rendering list styles at all.

Webkit's details implementation is entirely different. For Apple's browser, we have to reach for the internal pseudo-element selector ::-webkit-details-marker and hide it with display: none.

If we combine both approaches, we end up with the following CSS to remove the details triangles altogether.

/* Chromium / Firefox */
details summary {
  /* Either remove the list style ... */
  list-style: none;

  /* ... or change the `display` property to something else */
  display: flex;
}

/* Webkit */
details summary::-webkit-details-marker {
  display: none;
}

Side note: it's not great that major browsers ship different details element implementations. Luckily, this topic is included in Interop 2025, so we will see improvements this year.

Let's continue to make the elements a “real” accordion.

Connecting multiple `details` to build an exclusive accordion

Forcing all these details elements to be open one at a time is a trivial task in 2025 because you only need to set the same name attribute on all the elements.

<details open name="something">
  <summary>First entry</summary>
  <p>...<p>
</details>
<details name="something">
  <summary>Second entry</summary>
  <p>...</p>
</details>

That's it? Yes!

Connecting the details elements with the same name allows only one element to be open at a time. If one details element is opened, the others will be closed.

However, before you slap the same name attribute on all your details elements, be aware that exclusive accordions have accessibility and UX tradeoffs. In many situations, accessing information included in multiple elements is beneficial. For example, if extensive FAQs only allow one question to be open at a time, it will be terrible UX if someone wants to compare paragraphs. I would say that an exclusive accordion is “okay” for this small marketing widget, though.

With these few details tweaks, we implemented the core accordion functionality, and the component started to look like something real after adding some styling.

Animating the `details` content

At this stage, our details elements are connected and open only one at a time, but they're not looking perfect yet. The hidden content isn't animating or transitioning. How can we make the details content “slide open”?

To do that, we can reach into our CSS magic bag!

`::details-content` — the expandable/collapsible `details` content

To animate and transition the hidden accordion content, we need to find a way to select it first.

Wrapping everything in a div might be an option, but this approach often leads to CSS hacks and spacing issues. Chromium browsers ship a new solution to avoid these wrapper elements — ::details-content.

The new pseudo-element lets us select all the content that's not the summary element itself.

For example, if you want to color everything that shows up after clicking the summary element in red, you can set a background color on the ::details-content pseudo-element.

details::details-content {
  background: red;
}

Coloring this new pseudo-element isn't helpful, though, so let's use ::details-content for a sliding transition.

Animating height with `interpolate-size`

Now that we can select all the hidden content, you could think of adding an overflow: hidden to transition the height property, but, unfortunately, this won’t work.

/* This won't work yet */
details::details-content {
  overflow: hidden;
  height: 0;
  transition: height 0.3s;
}

details[open]::details-content {
  height: auto;
}

We can't animate from a <length-percentage> value like 0 to an intrinsic size value like auto in CSS. Or can we?

I have a surprise for you!

In Chromium, you can animate from 200px (or other values) to auto by setting interpolate-size. The allow-keywords value will instruct browsers to do some Math and allow transitioning from specific values to auto, min-content, and other keyword values. This new CSS property is a big deal!

It should be safe to turn on interpolate-size on the :root element, and all included elements will inherit this new setting.

:root {
  interpolate-size: allow-keywords;
}

And now look at this.

This sliding animation isn't perfect yet, but opening the details element looks pretty good already. However, what's up with the closing transition?

Transitioning properties like `display` or `content-visibility` with `transition-behavior`

If you inspect Chromium's details toggle behavior, you'll discover that the closed ::details-content element includes a content-visibility: hidden;. This CSS property prevents our closing slide transition from being visible.

Whenever we close the details element, content-visibility: hidden; is applied to the ::details-content pseudo-element. content-visibility makes any visible effect disappear immediately because there's nothing to transition when the value changes from visible to hidden. The element is just hidden right away.

If you ever wanted to create an exit animation and realized that it wouldn’t work because display: none will hide the element right away, this here is the same problem.

The question is how should browsers transition discrete values (hidden, visible, …)?

The default behavior is to flip the values immediately and ignore the fact that you defined a transition. This is why display: none or content-visibility: hidden are applied immediately.

Luckily, there are new ways to change this behavior! To enable easier transitions, we now have the transition-behavior property.

details::details-content {
  overflow: hidden;
  height: 0;
  /* Enable transitioning of `content-visibility` */
  transition: height 0.3s, content-visibility 0.3s;
  transition-behavior: allow-discrete;
}

By setting transition-behavior: allow-discrete we can tell the browser that it's okay to also transition properties that aren't based on numbers. If you allow discrete animations, the values won't be flipped immediately but at the 50% transition mark.

For special cases like display and content-visibility, the values will only be flipped when the entire transition is over. This allows us to transition other properties and set display: none at the end of a transition.

When we turn on transition-behavior for the ::details-content, the browser will only toggle to content-visibility: hidden at the end of the specified transition (0.3s).

And now check this out!

This visual effect might not look like a big deal, but after fifteen years of web development, I'm absolutely amazed by being able to transition height and animate from and to display: none. This is huge!

Now that our accordion looks good, how can we show images depending on the opened details element?

Reacting to DOM changes with the `:has()` selector

Let's bring in the images in the right column of the accordion component.

<div class="accordion">
  <!-- The left column -->
  <div class="detailsColumn">
    <details open name="something">
      <summary>First entry</summary>
      <p>...<p>
    </details>
    <details name="something">
      <summary>Second entry</summary>
      <p>...</p>
    </details>
  </div>
  <!-- The right column -->
  <div class="imagesColumn">
    <img src="..." width="1000" height="1000" alt="">
    <img src="..." width="1000" height="1000" alt="">
  </div>
</div>

Side note: to keep things simpler, I decided to treat the images as “decorative” with an empty alt attribute (alt=””). This way, we can transition opacity to show and hide the images without worrying about their exposure in the accessibility tree.

The accordion should, by definition, always include the same number of details and img elements. Would it be possible to show and hide images depending on which details element is currently open?

It might be a bit adventurous, but I love using :has() for these cases.

Let’s hide all the images with opacity: 0; and scale them up to make them appear with a nice transition when they become visible.

.accordion img {
  opacity: 0;
  scale: 1.1;

  transition: scale 0.3s, opacity 0.3s;
}

Next, let’s bring in some :has() magic to make the images appear when their details counterpart was opened.

.accordion:has(details:nth-child(1)[open]) img:nth-child(1) {
  opacity: 1;
  scale: 1;
}

I know, this selector is a mouthful. Let's dissect it!

From right to left: we want to show the image that is a first child (img:nth-child(1)) inside of an .accordion that includes an opened details element that's also a first child (details:nth-child(1)[open]). It takes a moment to wrap your head around it, I know…

However, with this selector, we’re matching the position of the open details element with the visible img element, and we can extend it to cover all the included accordion entries.

.accordion:has(details:nth-child(1)[open]) img:nth-child(1),
.accordion:has(details:nth-child(2)[open]) img:nth-child(2),
.accordion:has(details:nth-child(3)[open]) img:nth-child(3),
.accordion:has(details:nth-child(4)[open]) img:nth-child(4),
.accordion:has(details:nth-child(5)[open]) img:nth-child(5),
.accordion:has(details:nth-child(6)[open]) img:nth-child(6) {
  opacity: 1;
  scale: 1;
}

And now look at this!

Of course, this approach comes with a significant trade-off. To cover all the cases, you must hardcode a number of entries in your CSS. This obviously isn't great, but I'm okay with shipping a few more selectors to avoid some JavaScript onClick handlers.

And now we're almost done; only one tiny feature is missing.

You might have noticed it: when all details elements are closed, all images are hidden and, unfortunately, we can't prevent the details elements from getting closed.

There's an open HTML specification issue about this problem, but it doesn't seem to have gotten any traction.

To work around this problem, I think it’s fair game to bring in a fallback image. Let's add a .fallback image at the end of the images container…

<div class="accordion">
  <div class="detailsCol">
    <!-- ... -->
  </div>
  <div class="imagesColumn">
    <img src="..." width="1000" height="1000" alt="">
    <img src="..." width="1000" height="1000" alt="">
    <img class="fallback" src="..." width="1000" height="1000" alt="">
  </div>
</div>

… and show this image when there are no open details elements inside our .accordion container.

/*
  Show the `.default` image when `.accordion`
  doesn't include open `details` elements
*/
.accordion:not(:has(details[open])) .fallback {
  opacity: 1;
  scale: 1;
}

Et voilà!

I might sound like a broken record, but I'm absolutely amazed by all this CSS magic.

Conclusion

This was a wild ride, wasn't it?

In this post, we covered how to animate elements from height: 0; to height: auto;. We transitioned content-visibility from visible to hidden. And we wrote a funky :has() selector to react to all these details elements' opening and closing state.

All these new features show that the CSS evolution is in full swing, and it's enabling us to build things that we couldn’t build before. And I'm so here for building more with less code!

If you have any questions, let us know in the comments, shoot me an email, or tag us on social. And if you want to catch the next article teaching all this cutting-edge webdev stuff, subscribe to our newsletter below.

Until then — talk soon!

Written by

Stefan Judis

Stefan loves getting into web performance, new technologies, and accessibility, sends out a weekly web development newsletter and enjoys sharing nerdy discoveries on his blog.

🧢 Web Weekly newsletter 152 — Interop 2025, console.context() and Number.POSITIVE_INFINITY

Stefan Judis — Wed, 19 Feb 2025 04:14:43 +0000

Guten Tag! Guten Tag! 👋

What can we expect from Interop 2025? How can you give your console.log statements more context()? Is using gifs generally a good idea?

Turn on the Web Weekly tune and find all the answers below. Enjoy!

Pawel listens to “9th Wonder - LoveKiss”:

I can listen to this beat in a loop for the whole day. Just so good!

Do you want to share your favorite song with the Web Weekly community? Hit reply; there are three more songs left in the queue.

If you enjoy Web Weekly, let others know by reposting it on your favorite social network. It really helps me grow this newsletter into something "real". 🫣

🦋 Bluesky
🐘 Mastodon
💼 Linkedin

Thank you! 💙

The browser makers came together and decided on the focus areas of Interop 2025.

And if you now think, "Oh well... again, new stuff!?", I get it. However, the features included in Interop aren't browser APIs working in a single browser for the next decade. The promise is that all browsers support the listed features this year. These Interop features are supposed to enter the web soon'ish. For realz.

The Interop focus areas this year include:

CSS anchor positioning
Core Web Vitals
::details-content
import ... with { type: "json" }
CSS @scope
View Transitions
and many more things...

The "official Interop 2025 docs" are a good read, so check them out!

But what's the current state and where are we today?

Unsurprisingly, Chromium is leading the way in terms of new features, but I expect that things will move fast.

I'm quite happy with Interop 2025, but if you're game for some critical thoughts, of course, Alex Russel never disappoints and shares some spicy takes.🌶️

Something that made me smile this week

I resisted for over a year and didn't put stickers on my computer, but these are just too good!

Be a fake developer

New on the blog

TIL: How to iterate over TypeScript union types

Let's stop using animated gifs

Oldie but goldie: Martin makes some good points against using animated gifs.

Reconsider

LCP !== LCP

Did you know that not every element is considered a valid LCP element? Or are you aware that Chromium and Firefox evaluate the LCP elements differently? Matt explains the details.

Understand LCP

Why we should consider searchability

How do you search for things on a web page? You might CMD+f all the things. If you do, you've probably also encountered situations when a simple text search doesn't work.

Schepp explains how to make content findable for the built-in browser search and assistive technology using hidden="until-found" and some CSS trickery.

It's an excellent post, and I wonder if this approach will become a .sr-only class replacement.

Make things searchable

`console.context()`

Today I learned that the Chromium console includes a context() method that allows you to create loggers, which you can easily filter in the JavaScript console.

Filter your logs

You're halfway through! Would you enjoy getting Web Weekly straight to your inbox?

The wonderful weird web – Floor796

Floor796 is an absolute classic created in 2018, and the animated space station includes areas with a gazillion tiny details. The fun thing: the project is still being worked on and extended.

Discover things

Is AI hindering new tech adoption?

I'm really trying to lean into some AI coding features, but with all these new browser features shipping daily, I would be lying if I said I'm not concerned about the AI knowledge cut-off.

Be aware of the new stuff

Speculation rules on `google.com`

You might have heard of the Chromium-only Speculation Rules. They're supposed to be a prefetch / prerender alternative.

I learned that Google Search ships them in production, and their implementation includes many tips and tricks about things to consider. I mean look at this snippet, "anonymous-client-ip-when-cross-origin", what? 🤯

Speculate

A 💙 for CSS grid

I just love it when I see CSS grids being used for more than putting columns next to each other.

Power up your grids

A massive Node.js ecosystem update

This news might only be important for package maintainers, but after all these years of dancing the endless CommonJS vs ECMAScript modules dance, it's finally time to embrace modules.

Node.js 20 and higher versions can now require ECMAScript modules, which means that when Node.js 18 reaches the end of life in April, everybody can drop all these build steps compiling multiple module systems and "just ship" modules.

Go all-in with modules

Random MDN – `Number.POSITIVE_INFINITY`

From the unlimited MDN knowledge archive...

Here's one of the many famous JavaScript quirks: did you know there's a static data property called POSITIVE_INFINITY? Now you do.

Discover infinity

TIL recap – media query boolean contexts

Here's a trick question: what values will be matched for the prefers-contrast media feature query when you omit the value and use the so called "boolean context"?

Query features!

Find more short web development learnings in my "Today I learned" section.

New on the baseline — Styling scrollbars

Short'n'sweet: if styling the scrollbar is your jam, scrollbar-color and scrollbar-width work across modern browsers now!

Be on brand

Three valuable projects to have a look at

yassinebenaid/bunster – Compile shell scripts to static binaries.
GyulyVGC/sniffnet – Comfortably monitor your Internet traffic.
PatrickJS/awesome-cursorrules – A list of awesome .cursorrules files.

A new Tiny Helper

Addy continues his tooling journey! There are now a tool to remove backgrounds from images, a tool to compress images and the newest member — a tool to compress videos.

Compress your videos

Find more single-purpose online tools on tiny-helpers.dev.

Thought of the week

In the spirit of the web platform, here's some wisdom from Harry:

Every layer of abstraction made in the browser moves you further from the platform, ties you further into framework lock-in, and moves you further away from fast.

Did you learn something from this issue?

💙 If so, join 21 other Web Weekly readers and give back with a small monthly donation on Patreon or GitHub Sponsors.

This is all, friends!

Loved this email? Hated this email? I want to hear about it!

If you think something needs improvement or something sparked some joy, reply to this email because I want to know more!

And with that, take care of yourself - mentally, physically, and emotionally.

I'll see you next week! 👋

🧢 Web Weekly 151 — `popover` enters the baseline!

Stefan Judis — Wed, 12 Feb 2025 18:49:33 +0000

Guten Tag! Guten Tag! 👋

Do you know what the European Accessibility Act will mean to you? Are view transitions (SPA or MPA) ready for production yet? Have you heard that popover is now on the baseline?

Turn on the Web Weekly tune and find all the answers below. Enjoy!

Khaled listens to "Cinematic Orchestra feat. Patrick Watson - To Build A Home"

I listen to this song every now and then for about 14 years now!

Do you want to share your favorite song with the Web Weekly community? Hit reply; there are two more songs left in the queue.

I'm a day late, so I'll keep this week's intro short, but I want to welcome all the new subscribers who joined last week! 👋

It's great to see Web Weekly growing, and if you have any comments, questions, or want to send over "good web stuff"™, let me know!

I'm all ears (eyes? 🤷) and enjoy every bit of webdev chatter in my inbox!

With that — let's go!

Something that made me smile this week

I'm unsure if getting scared is the right approach to breaking social media addiction, but if you try TabBoo let me know how it went.

Break bad habits

New on the blog

The European Accessibility Act (EAA)

The European Accessibility Act will go into effect on June 28, 2025, and Martijn shares what you need to know.

Understand the EAA

On native CSS nesting

Andy argues that browsers shouldn't have shipped native CSS nesting because it's a solely developer convenience feature that also comes with some footguns.

I'm unsure if I agree with this statement, but the article includes wise words worth pinning on your monitor. When you write code, ask yourself:

Could a junior developer understand this code?

💯 Future me will smartass the heck out of this idea. Get ready!

Understand nesting

It's about people

This page isn't new, but it's so valuable. The WEC Web Accessibility Initiative put together user stories about making digital products more accessible.

Bookmark it for the next time when someone tells you that accessibility is "about X".

Build for people

How to favicon in 2025

It's the time of the year again when the wonderful Martians research how to load a favicon the best way. 👆 Do the necessary spring cleaning if your sites include more HTML than this to load a favicon.

Clean up your favicons

The wonderful weird web – Stripe's Black Friday stats

Stripe must be doing very well when they have the time and money to build info pages like this one. 👆 Either way, it's fun to play with all the Black Friday stripe transaction data.

Check the stats

Stripe also released this fabulous developer portal not too long ago.

Replace your animation libs with `startViewTransition()`

In my opinion, view transitions are the biggest update the web has seen in many years because we can build so many cool effects with so little effort now.

I used startViewTransition() to rebuild a navigation component that relied on a heavy JS animation lib with ~50 lines of CSS.

Read the post Watch the video

Get started with MPA view transitions

Cross-document view transitions allow us to animate and transition elements across good old HTML navigations. The new @view-transition at-rule has been supported in Chromium for a while, and Safari started supporting it last December.

If you want to spice up your static HTML sites, Kevin and Bramus live coding session will get you up to speed!

Transition across pages

Managing focus

Ollie explains the differences between :focus and :focus-visible, and why the focus() DOM method needs an update.

Focus!

Some WebDev Trivia...

I admit I've never thought about this and didn't know. But do you know?

Travel in time

How to start a blog

Unsurprisingly, blogging had a huge impact on my career (heck, my life even?).

Blogging helps me order my thoughts, learn new things, become a better writer, get invited to more job interviews, connect with people — the list goes on and on. I should probably blog about the benefits of blogging.

If that sounds convincing and you wonder how to get started, here's some solid advice.

And don't forget to send me your RSS feed if you kick things off and start a new blog.

Random MDN – `:user-valid` / `:user-invalid`

From the unlimited MDN knowledge archive...

Do you know that there are CSS classes that match valid/invalid form elements only after the user interacts with them? Now you do!

Validate at the right time

TIL recap – table `caption`

Be honest. Do all your HTML tables include the required caption element?

Give your tables a proper name

Find more short web development learnings in my "Today I learned" section.

New on the baseline — `popover`

Big news: the popover API is now "newly available" on the baseline, and if you're now thinking, "Hold on! Wasn't it baseline ready last year already?", that's right.

But webdev, spec work and browser implementations are hard. Rachel explained what happened and shared insights on how the baseline baseline evaluation works.

Pop over!

Classifieds & friends

If you can't get enough of WebDev news, I can highly recommend Adam's WeeklyFoo newsletter. It pairs wonderfully with Web Weekly to catch all the relevant web dev news!

Three valuable projects to have a look at

sindresorhus/emittery – A simpl and modern async event emitter.
localsend/localsend – An open-source cross-platform alternative to AirDrop.
yamadashy/repomix – A tool to pack your entire repository into a single, AI-friendly file.

A new Tiny Helper

When I blogged about font-family: system-ui, a few people pointed me to Modern Font Stacks. What is it?

Modern operating systems come with more installed fonts than Arial. Modern Font Stacks lets you play and test available fonts, so you don't have to deal with optimal font loading strategies.

Use what's already there

Find more single-purpose online tools on tiny-helpers.dev.

Thought of the week

Addy shared his thoughts on all this AI for coding madness happening right now, and his opinion might surprise you.

AI tools help experienced developers more than beginners.

Did you learn something from this issue?

💙 If so, join 21 other Web Weekly readers and support this small indie newsletter with a small monthly donation on Patreon or GitHub Sponsors.

This is all, friends!

Loved this email? Hated this email? I want to hear about it!

If you think something needs improvement or something sparked some joy, reply to this email because I want to know more!

And with that, take care of yourself - mentally, physically, and emotionally.

I'll see you next week! 👋

Replace your JavaScript Animation Library with View Transitions

Stefan Judis — Wed, 05 Feb 2025 14:14:28 +0000

I've always wanted the web to win, full stop. When I compared the web experience to mobile apps, however, it always felt like the web was losing. After all these years, the web still feels like a collection of documents linked without delight or an excellent user experience. Don't get me wrong, with the CSS evolution in full swing; we got many new and useful features, but it was still missing an easy-to-use API to animate, move, and even morph elements into each other…

Even simple animations like the ones below required wild and unmaintainable CSS hacks or heavy JavaScript animation libraries.

For those rooting for the web, 2025 has now exciting news! Both Chrome and Safari shipped a new and fairly straightforward way to add animations and transitions to your sites — say “Hello” to the View Transitions API.

Let me show you how view transitions work by recreating this animation effect with a few freckles of modern web technology. A web technology that is probably the most significant web platform update in years.

Generating markup from your design

Whenever I want to quickly sketch something out (like the code for this blog post), I reach for Builder's Visual Copilot. Design something in Figma, import the design into Builder using the Figma plugin, and off you go.

With a single command, you'll be ready to pull your codified design into your codebase.

Pure HTML, React, and even Swift exports are available to give you a headstart. It's pretty sweet!

But let's get to some animation magic.

The base setup

To explain the view transition core concepts, we'll use a vanilla approach to rebuilding this animated navigation — HTML, CSS, and good old JavaScript to toggle an active class.

That will be it; there won't be animation libraries or other external dependencies. All included concepts can be applied to sites built with or without frameworks.

If you're wondering how to apply view transitions to your React, Vue, or Angular app, you'll find resources on web.dev.

So, where do we get started?

Here's the HTML we'll use:

<main>
  <nav>
    <a href="#" class="active">Home</a>
    <a href="#">Projects</a>
    <a href="#">About</a>
  </nav>
</main>

Nothing fancy — it's just a list of links.

And here's some basic JavaScript to toggle the active class on all the included navigation links on click.

const allLinks = document.querySelectorAll("a");

allLinks.forEach((link) => {
  link.addEventListener("click", (event) => {
    setActiveItem(event.target);
  });
});

function setActiveItem(element) {
  allLinks.forEach((link) => link.classList.remove("active"));
  element.classList.add("active");
}

The CSS will be pretty common stuff, except for the background of the active link element. The active link’s background isn’t rendered on the link itself but rather a pseudo-element. We'll need this extra pseudo-element to animate and slide it around later on.

a.active::before {
  content: "";
  position: absolute;
  inset: 0;
  background-image: linear-gradient(to right, #6a11cb 0%, #2575fc 100%);
  z-index: -1;
}

Here's a live preview of how the project looks so far:

Getting started with JavaScript view transitions

So, what are they — these view transitions? Here's what MDN has to say about them:

The View Transition API provides a mechanism for easily creating animated transitions between different website views. This includes animating between DOM states in a single-page app (SPA), and animating the navigation between documents in a multi-page app (MPA).

View transitions allow you to take screenshots of DOM elements, then modify the DOM and magically transition from the old view to the new DOM representation.

In this article, we'll cover the animation between different DOM states triggered via JavaScript (the SPA mode), but we will cover cross-document transitions in the future here on the blog. Check the newsletter box in the footer if you want to catch the next article.

But let's get started, and I'll explain the concepts along the way. At the core of view transitions is the startViewTransition JavaScript method.

Here's the getting-started example snippet from the view transitions web.dev guide.

function handleClick(e) {
  // Fallback for browsers that don't support this API:
  if (!document.startViewTransition) {
    updateTheDOMSomehow();
    return;
  }

  // With a View Transition:
  document.startViewTransition(() => updateTheDOMSomehow());
}

To animate between DOM states, you pass a callback function to startViewTransition that modifies the DOM. You could add new DOM nodes or add or remove classes; either way, the browser will transition between the old and new DOM states.

A quick note about browser support: Safari and Chromium support the new API at the time of writing, and I recommend treating view transitions as a progressive enhancement. Chromium and Safari (90% global share) users will then see the new and fancy web. For me, that's good enough, and I bet the rest won't miss it.

Luckily, view transitions support is easy to detect. If document.startViewTransition is available on the document object, you can use the API to create transitions and animations. If it's not, you update the DOM as usual, and people on older browsers or Firefox won't see smooth transitions. In my opinion, that's a good trade and better than loading tons of JavaScript for everybody.

Let's add startViewTransition to our example.

const allLinks = document.querySelectorAll("a");

allLinks.forEach((link) => {
  link.addEventListener("click", (event) => {
    // Fallback for browsers that don't support this API:
    if (!document.startViewTransition) {
      setActiveItem(event.target);
      return;
    }

    // Update the DOM with a view transition
    document.startViewTransition(() => setActiveItem(event.target));
  });
});

The code is now similar to the initial example; the only change is that setActiveItem is now called by startViewTransition if the browser supports it.

And look at this, with this minor tweak, we already see a cross-fade happening for the active element:

Pretty cool, right? But what's going on, and how does this work?

The browser will attach new pseudo-elements to the DOM whenever you start a new view transition. You can see these elements in the Chrome dev tools while a view transition is happening.

Above, you see Chrome's animation tooling (you can open it with CMD+Shift+p and search for “animation”) that I use to debug the triggered view transition. Thanks to the animation tooling, we can see the view transition pseudo-elements in the DOM and even slow down the animations. Very handy!

::view-transition-old() is a screenshot of the old DOM state whereas ::view-transition-new() is a live representation of the new DOM state. The old DOM screenshot is then transitioned to the new live DOM presentation. By default, this is done with a fade and mix-blend transition. But what are we transitioning here?

If you look closely, you see that by using startViewTransition, the browser will take the root element (the html element) take a screenshot of it, and fade to the newly updated HTML DOM state. Just like that? Yep, you can add cross-fade transitions to your sites with a JavaScript one-liner.

That's fun, but why stop there? Let's build up our navigation component and animate more than the root element.

Use `view-transition-name` to animate elements separately

When we look at our target components from the beginning, we want to animate the active nav element separately. How can we achieve this?

For these use cases, we can specify in CSS that we want to have another animation group with the view-transition-name property.

/* Move the active link into its own view transition layer */
a.active {
  view-transition-name: active-nav-elem;
}

And look at this: this animation effect isn't quite what we're after, and it's not perfect yet (notice this small visual glitch), but it's quite impressive for a single line of CSS.

If you inspect the DOM, you'll discover that there are more view-transition- pseudo-elements.

View transition pseudo-elements rendered in the DOM.

We still have the view transition elements for root, but there are now also elements for our active link (active-nav-elem), which was put into its own group by applying the view-transition-name property.

The ::view-transition-group(active-nav-elem) transitions the elements’ positioning, transform, width, and height properties. Remember, it's a screenshot of the old active link and a live presentation of the new active link, and the browser transitions from one to the other. It doesn't matter that transitioning active links are completely different DOM nodes. The browser will just figure it out and visually morph one element into the other. Wild!

What you see above is that the active link view transition is rendered above on top of a cross-fade root view transition. That's why it looks like links are fading away under the active element, but, in practice, it's the entire root element doing a cross-fade. Pretty cool, right?

Next, let's fix this visible glitch in the active element transition.

The problem is that the transition group tries to transition two elements with different dimensions and aspect ratios. The “Home” link is smaller than the “Projects” link.

To smoothen the transition, we can target the two pseudo-elements in CSS, tweak the animation, and define that they both should match in height while still doing the cross-fade.

/* Apply the same height to ease the view transition */
::view-transition-old(active-nav-elem),
::view-transition-new(active-nav-elem) {
  height: 100%;
}

Isn't this cool?

Even though it looks pretty fancy already, this isn't the effect we are looking for. How could we make the highlighted gradient box slide under the text?

Apply view transitions to pseudo-elements

Do you remember that the background gradient was done with a ::before pseudo-element instead of setting a background on the active link? Now that we know about the view-transition-name property, we can animate the pseudo-element instead of the entire link.

/* Move the background to its own view transition layer */
a.active::before {
  view-transition-name: active-nav-elem;
}

And again, this doesn't look too bad for such a tiny change. Does it?

But the background view transition is now covering the text fragments. How can we move the text on top of the ongoing background transition?

We can put all the links into their own view transition layers and control all the view transition pseudo-elements with a z-index!

This could be done right in CSS…

/* Move all the links into their own view transition layer */
a:nth-child(1) {
  view-transition-name: nav-1;
}

a:nth-child(2) {
  view-transition-name: nav-2;
}

a:nth-child(3) {
  view-transition-name: nav-3;
}

…and this kind of works, but if you use a templating engine or a framework, you're better off defining the view transition names in HTML with inline styles. It's more maintainable and will guarantee that you don't need to touch your CSS if you update the number of navigation items.

<main>
  <nav>
    <a href="#" class="active" style="view-transition-name: nav-1;">Home</a>
    <a href="#" style="view-transition-name: nav-2;">Projects</a>
    <a href="#" style="view-transition-name: nav-3;">About</a>
  </nav>
</main>

This looks better, but still not quite right.

When navigating forward, the background is placed under the text fragments, but you still see the background covering the text when going backward. Why's that?

We didn't apply the z-index to all our view transitions yet!

Applying `z-index` to separate view transitions

By default, view transitions are stacked on top of each other depending on where they are defined in the DOM. If the active link pseudo-element is first in our navigation, the view transition pseudo-elements look as follows.

View transition pseudo-lements highlight in DevTools. The ::view-transition-group(active-nav-elem) is highlighted on third position.

We have the first text link (nav-1) and then the pseudo-element on top of it. And going on, the nav-2 and nav-3 text elements are on top of the background pseudo-element.

If we transition from the third link being active, the active-nav-elem transition layer comes last and covers all the text links when it transitions.

View transition pseudo-lements highlight in DevTools. The ::view-transition-group(active-nav-elem) is highlighted on last position.

We need to apply a z-index to our text layers to fix this. But how?

To apply custom styles like the z-index to the transition layers, we can target the transition groups in CSS.

/* Stack the text over the animated background */
::view-transition-group(nav-1) {
  z-index: 1;
}
::view-transition-group(nav-2) {
  z-index: 1;
}
::view-transition-group(nav-3) {
  z-index: 1;
}

But hold on, isn't this the problem of having a hardcoded number of items in our CSS? That's correct, and there's a solution, but I wouldn't recommend using it in production yet.

You could rely on the view-transition-class property to target multiple view transition pseudo-elements, but its browser support isn't great yet (Chromium and recent Safari). MDN doesn't even have a docs page for it.

View transition classes work similarly to “normal” classes. Give multiple elements the same view transition class and target the resulting layers with the view-transition pseudo-element selectors.

/* Define a view transition class to target multiple view transition layers */
a {
  view-transition-class: nav-item;
}

/* Apply styles to multiple view transition layers */
::view-transition-group(.nav-item) {
  z-index: 1;
}

If you're on Chromium or a recent Safari, here's the fixed stacking context with cutting-edge CSS.

So, as of now, I recommend hardcoding the view transition layers until view-transition-class has better browser support. It’s not pretty, but it's not too bad, either. This article is excellent if you want to read more about view transition classes.

There's one last bit of fanciness I want to add, though!

Controlling view transitions with custom easing functions

The background pseudo-element is now smoothly sliding below all the text links and it's looking pretty good, but I think it could look a bit more fun. Let's make it bounce and apply some custom easing functions to the transition group, that's wrapping the background element.

Remember, view transitions are all about CSS; we can go in, apply a custom easing function, and even control the time of our background element transition.

:root {
  --bounce: linear(
    0,
    0.271 8.8%,
    0.542 19.9%,
    0.837 34.2%,
    1 44.7%,
    0.943 51.1%,
    0.925 57.5%,
    0.937 63.1%,
    1 77.4%,
    0.991 84.2%,
    1
  );
}

/* Tweak the active background animation */
::view-transition-group(active-nav-elem) {
  animation-timing-function: var(--bounce);
  animation-duration: 0.375s;
}

If you haven't seen the linear() easing function yet, it allows us to create bouncy effects like the one below. You probably don't want to code these by hand, however, which is why I recommend using the Easing Wizard.

And now, look at the final result!

I don't know about you, but I'm pretty excited about all this!

Quick side note: if you now go ahead and create animations heavily moving DOM elements around, be a good web citizen, and allow people to opt-out by using @media (prefers-reduced-motion) {}.

Conclusion

View transitions allow us to finally push the web to the next level and I'm so there for it!

I hope this small example shows the power of the new View Transitions API. We needed roughly 50 lines of CSS to build something that would usually require thousands of lines of JavaScript locking your CPU. The future is bright (and animated).

If you want to learn more about view transitions, let us know in the comments, shoot me an email, or tag us on social. If we get great feedback, we'll publish more articles on the matter soon. Oh, and make sure to subscribe to our newsletter below if you want to catch more articles on this topic.

Until then — have fun dropping some heavy animation libraries from your code bases!

Written by

Stefan Judis

Stefan loves getting into web performance, new technologies, and accessibility, sends out a weekly web development newsletter and enjoys sharing nerdy discoveries on his blog.

Animate hero elements with scroll-driven CSS animations

Stefan Judis — Mon, 16 Dec 2024 13:19:45 +0000

When you navigate to github.com (you must be logged out because otherwise you'll enter the GitHub app), you'll be greeted by this landing page.

It's a well-designed centered hero design with a sign-up box. It stands out that the hero text fades away while moving behind the code editor once you scroll down. How can you achieve such an effect?

I was curious and kicked off a quick reverse engineering session to discover that everything's built with React, and the application listens to scroll events. When scrolling, the JS updates the hero text's scale and opacity properties in a requestAnimationFrame loop. In short, a lot is going on to create this effect!

In this article, I will explain how to achieve a similar effect with modern (and future) CSS and zero JavaScript.

If you want to look at the final example, check a deployed demo version online!

Some prep work

To have some code ready, I quickly designed a hero section in Figma and used the Builder Figma plugin to generate some React code with Visual Copilot.

While my Figma-to-code result is less pretty than the GitHub example, this workflow lets me create something to work off in five minutes.

Sliding the hero image over the text with `position: sticky`

A reasonable first step to recreate the GitHub effect is to slide the hero image over the hero text.

To do this, we can stick the hero text at the top while scrolling. By using position: sticky, we can place an element inside a container and "make it stick" somewhere when people scroll around.

To give the hero text some air, we'll also add some space using the top CSS property.

.hero-text {
  /* Make the element sticky */
  position: sticky;
  /* Give the element some space at the top */
  top: 1rem;
}

When we add position: sticky, we'll discover that the hero text scrolls on top of the other scrolling elements. This is exactly what you want in most sticky scenarios, but in our case, we want the sticky element to go below the rest.

To make the hero text "slide under", we need to create a new stacking context for the other elements. There are many ways to do this, but I like to set isolation: isolate to create a new stacking context because it's a nifty one-liner, and more people should know about the isolation CSS property.

.hero-image {
  /* Create a new stacking context */
  isolation: isolate;
}

And voila — look at this!

That's not too shabby, isn't it? Now, we only need to add the scroll-fade behavior. How can we add it?

Adding CSS-only scroll-driven animations

If you're reading this blog, you're probably aware of the ongoing CSS evolution. Let me tell you, there hasn't been a better time to be a web developer. To name a few recent CSS features: we now have container queries, the :has() selector entered the stage, and view transitions make animating things easier than ever before.

The modern web is fantastic, and one other exciting feature in the making is scroll-driven CSS animations. Scroll what? Yes, you heard that right!

What are scroll-driven CSS animations?

Scroll-driven animations allow you to remove all these custom JavaScript scroll handlers and use the CSS Animations API to add scroll animation behavior.

The API runs off the main thread and provides a massive performance boost compared to thousands of firing scroll handlers in JavaScript land. With scroll-driven CSS animations, you can create scroll effects with less and more performant code.

The new CSS feature is currently supported only by Chromiums, but Webkit is open to this platform addition, and Firefox ships an initial implementation behind a flag! Native scroll-driven animations will be coming to the web!

If Chromium-only isn't good enough to use the new CSS feature yet, I understand. However, with Chromium-based browsers having a global market share of over 70%, it's fair to treat scroll effects as progressive enhancement. Browsers that support scroll-driven animations will show users some eye candy, while the other browsers will only render a headline on top of a hero image.

Side note: if scroll-driven animations are essential for your site, there is also a polyfill. I haven't used it, but it might be a valid alternative to add custom scroll behavior.

But let's get to it and add some eye candy!

Adding your first scroll-driven animation

Scroll-driven animations are based on good old @keyframes.

@keyframes fade-out {
  0% {
    opacity: 1;
    scale: 1;
  }

  100% {
    opacity: 0;
    scale: 0.5;
  }
}

We can define a fade-out animation that makes an element disappear by scaling it down and reducing its opacity. Next, we take our hero-text class and set our scroll-driven animation.

.hero-text {
  /* Set the animation */
  animation: fade-out linear;
  /* Connect the animation to the nearest scroller's scroll progress */
  animation-timeline: scroll();
}

And look at this: two added CSS declarations give us something to work off of already.

Let's understand what's going on here!

The hero-text class now sets the fade-out keyframes using the animation property. It isn't a "normal" animation declaration, though.

The animation shorthand doesn't define an animation-duration. Usually, time controls the keyframe animation progress, but in our case, the animation-duration is set to auto because we want to make it dependent on scroll progress and a scroll timeline.

Below the animation declaration, you'll see the new animation-timeline property. Theoretically, animation-timeline is also part of the animation shorthand, but you can only use it to reset a timeline. To define an animation other than auto we must define an animation followed by a specified animation-timeline. Order matters in this case!

But I got ahead of myself; what's an animation timeline?

Specifying an animation timeline

An animation timeline specifies the timeline used to control the progress of a CSS keyframe animation. Usually, you control your animations by time which maps to animation-timeline: auto. But with scroll-driven animations, there are now two new animation scroll timelines: scroll progress (animation-timeline: scroll()) and view progress (animation-timeline: view()) timelines.

Animating the hero element on scroll progress (`scroll()`)

A scroll progress timeline defined with the scroll() CSS function maps the scroll progress of a wrapping scroll container (also called scroller) to values from 0% to 100% and applies them to a keyframe animation. In our case, the nearest scroll container is the html element. When scrolling down, the overall document scroll progress controls the fade-out animation.

And while this works, you might now wonder what happens with massively long HTML documents.

When the fade-out animation relies on document scroll progress, a** longer document affects the animation progress.

scroll() comes in handy if you want to display a document scroll progress indicator, but for our hero animation, it doesn't make sense to use a scroll progress timeline. If you scroll 500px down in a 2000px high document, the animation will progress by 25%. But when the document grows to 10000px, the scroll timeline will only progress to 5%. The animation will be barely noticeable. Our animation should rely on something other than the document length!

Luckily, we can use another scroll timeline.

Animating the hero element on view progress (`view()`)

If you don't want to consider the overall scroll progress, there's another way to control scroll-driven animations. The new view() CSS function allows you to consider the visibility of an element inside a scroller. The view() function is quite a beast to wrap your head around, but most importantly, view progress timelines are also wildly powerful!

I will only go into some of the details here (check the resources below if you want to learn more), but let's take a step back to rethink how the visual effect should work.

We want to:

Start the keyframe animation at 0% when our hero starts moving off the screen.
Finish the keyframe animation at 100% when the hero disappears.

To achieve this behavior, we have to adjust the animation range, and of course, there's another new CSS property for it — say hello to animation-range. animation-range enables us to define the start and end of our scroll-driven animation. For our fade-out animation, we're interested in kicking off the animation when an element starts disappearing (0%) until it's entirely gone (100%).

For this use case, we can add an exit animation range. Let's go ahead and put this into the CSS.

.hero-text {
  animation: fade-out auto ease-in-out;
  animation-timeline: view();
  /* Apply a custom animation range */
  animation-range: exit 0% exit 100%;
}

When you add the custom animation range, you'll discover that, for our hero animation, it doesn't work, though.

We defined the hero text to be sticky, and this positioning implies that it will leave the scroller only when the surrounding container is moving off the screen. The hero text animation is applied, but it's not visible because our hero dummy image covers the scroll exit animation.

When we remove the stickiness, we'll discover that our animation-range works appropriately. What can we do now that we want to animate a sticky element?

Attaching a named view progress timeline to animate sticky elements

Of course, the new scroll-driven animations have a solution to this problem, too. To make our animation visible, we need to control the animation depending on the view progress of another element with a named view progress timeline.

In our CSS, we can go into the wrapping hero container and specify a view-timeline-name…

.hero-container {
  /* Define a named view progress timeline */
  view-timeline-name: --hero-scroll;
}

… to then change our hero text to use the view timeline instead of view().

.hero-text {
  animation: fade-out auto ease-in-out;
  /* Specify the container animation timeline */
  animation-timeline: --hero-scroll;
  animation-range: exit 0% exit 100%;
}

And now check this out!

Our hero text element fades out and scales down right when the surrounding container starts leaving the screen. And how much CSS did this take us to write? It was only a few CSS declarations and one keyframe animation. I'm amazed!

Let's consider a few more things to be good web citizens, though.

Watching out for browser support and user preferences

First, some folks can feel discomfort or even sickness when faced with unexpected movements on screen. To build "a good web™", we can add a CSS reduced-motion media query to allow people to opt out of moving animations.

Second, while creating the demo, I discovered that Firefox's flagged implementation doesn't support the animation-range property yet. To resolve this, we can also add a @supports feature query to avoid a broken animation in browsers that don't support scroll-driven animations yet.

If you ask me, the fallback looks excellent as well, but of course, you could also remove the stickiness if you don't like the image sliding over the text.

So, here's the final code.

@supports (animation-range: exit) {
  @media (prefers-reduced-motion: no-preference) {
    .hero-container {
      view-timeline-name: --hero-scroll;
    }

    .hero-text {
      animation: fade-out auto ease-in-out;
      animation-timeline: --hero-scroll;
      animation-range: exit 0% exit 100%;
    }
  }
}

.hero-text {
  position: sticky;
  top: 1rem;
}

.hero-image {
  isolation: isolate;
}

@keyframes fade-out {
  0% {
    opacity: 1;
    scale: 1;
  }

  100% {
    opacity: 0;
    scale: 0.5;
  }
}

Isn't this magical and fun? I'm a big fan!

Conclusion

So, with only a few lines of modern CSS, we rebuilt this JavaScript-heavy effect on GitHub's landing page. Our scroll animation is now more maintainable and performant because we're not relying on any JavaScript blocking the main thread!

And because we're relying on modern CSS paired with progressive enhancement, we can give users the best experience if their browsers support it. Win-win!

If you want to see the effect in action, here's the deployed version.

Are you hooked already? I indeed am!

Next steps

If you want to learn more about scroll-driven animations, there's a single place to go. Bramus from the Chrome DevRel team, aka "Mr. ScrollAnimation", maintains scroll-driven-animations.style. The site lists many tools, resources, and visual examples.

If you prefer learning with videos, Bramus has also released a free course on YouTube.

And if you wonder how to debug scroll-driven animations, this Chrome extension is invaluable for figuring out what's going on.

And now we're done, have fun animating, and let me know how it goes!

Written by

Stefan Judis

Stefan loves getting into web performance, new technologies, and accessibility, sends out a weekly web development newsletter and enjoys sharing nerdy discoveries on his blog.

Forms without an accessible name are not exposed as ARIA landmarks

Stefan Judis — Fri, 19 Jul 2024 13:51:23 +0000

Suppose you want to be a good web citizen; you use semantic and accessible HTML. Elements "leading places" are a elements, your navigation lives in a nav element, buttons are ... well ... buttons, and your form controls are surrounded by a good old form.

Using the correct elements gives your HTML meaning. Semantic markup helps machines understand what they're dealing with. Googlebot slurping in your site will understand the important sections of your articles because it finds their headings. Assistive technology like screen readers can offer features and a better UX to navigate your site. Throw away the div soup and go for semantic HTML. It's great stuff!

For example, I can fire up VoiceOver on my Mac and navigate my site via all the exposed ARIA landmark regions exposed from semantic HTML.

banner maps to the header element, navigation is the nav element. And if an element has an accessible name, it's also listed next to its ARIA role. Good stuff!

If you look at the navigation landmark, I added the accessible names of Main and Footer because the page has two nav elements. The articles are enriched with their title, too.

But hold on! I know that there's a form on the page. Why isn't the newsletter signup form shown in the landmarks overview from VoiceOver?

As a first step, I opened the devtools to inspect the accessibility panel.

role=generic? My form element didn't come with an accessible form role but generic? I feel betrayed.

A quick look at the ARIA specs unveils the answer.

A form is not exposed as landmark region unless it has been provided an accessible name.

Wow! If you're not setting accessible names on your forms, they won't have the form role, which means they're not marked as forms and thus hard to discover and inaccessible.

How can you provide an accessible name?

There are many different ways, and each depends on the element.

A heading, for example, receives its accessible name from its content. Easy. Form controls receive it from their connected label. Label your inputs, folks! It really depends on the element. If you're curious and want to learn more, read the guide "Providing Accessible Names and Descriptions". But what about forms, then?

Here's a bit more guidance from the WAI-ARIA 1.3 spec:

Authors MUST give each element with role form a brief label that describes the purpose of the form. Authors SHOULD reference a visible label with aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible.

That makes a lot of sense. If you build up a form, there should be something nearby telling what this form is about. If it is, you can connect the form with the element representing its purpose via aria-labelledby and provide a nice accessible name.

<form aria-labelledby="form-heading">
  <h2 id="form-heading">Newsletter sign up</h2>
  <!-- more form stuff -->
</form>

If you can't include a visual heading for "reasons", you can also fall back to providing a string value via aria-label. But note that a form including a visual explanation of what it's about comes with a better user experience, and aria-label may also break if folks use in-browser translations.

<form aria-label="Newsletter sign up">
  <!-- more form stuff -->
</form>

With these tweaks, my form now shows up in VoiceOver, is enriched with an accessible name and has a proper form role.

Success!

TIL — How to exclude elements from being shown in Google Search results

Stefan Judis — Fri, 19 Jan 2024 06:14:02 +0000

Let's look at what happens when I google myself.

Of course, I know how my site is structured, and I can tell that Google displays my site's title and the description includes some of the root page's headlines. The description is not the worst, but it certainly could be better.

Is there a way to exclude elements from being shown in the Google snippet?

Today I learned that there is! And the solution is based on an HTML data attribute: data-nosnippet. Here's the example snippet from the Google Search Central docs:

<p>This text can be shown in a snippet
<span data-nosnippet>and this part would not be shown</span>.</p>

<div data-nosnippet>not in snippet</div>
<div data-nosnippet="true">also not in snippet</div>
<div data-nosnippet="false">also not in snippet</div>

data-nosnippet works on div, span and section elements, and it doesn't care what value you'll give it. data-nosnippet="true" and data-nosnippet="false" have the same result — signaling that this element shouldn't pop up in the Google Search results. Nice!

If you're unhappy with the search results, add some juicy data attributes now. But remember to trigger a reindex in the Search Console. Otherwise, it might take a while until your changes have an effect.

Using Playwright to Monitor Third-Party Resources That Could Impact User Experience

Stefan Judis — Wed, 15 Feb 2023 16:03:57 +0000

Today’s web consists of lots of 3rd party resources. Let it be your fonts, transformed and optimized media assets, or analytics and ad scripts, many sites out there include resources that they don’t own. Your website probably has a lot of those dependencies, too!

And while implementing third-party resources has downsides for performance and you should self-host your assets when possible, sometimes relying on external files is unavoidable. But be warned — using them can sometimes cause real headaches.

As Chris Coyier pointed out, external resources are often integrated too tightly into your own code, or implemented the wrong way, so that things can really go sideways. Ad blockers could block your external scripts or a service vendor could be down. Both situations can result in frontend downtime, poor UX, or entirely broken functionality on your end.

And while Chris asks if you could detect the cases of broken sites due to ad blockers with end-to-end testing, I think it’s more about all the 3rd party code running on the internet.

But heck yeah, testing and monitoring of failing external resources is possible!

Let’s have a look at an example that could be affected by 3rd party code and ways to monitor your stack with Playwright to guarantee that no external providers or ad blockers can mess with your business. 🫡

Examples of problematic external resource usage

But first, let’s look at patterns that can break your sites.

In my experience, there are two challenging 3rd party resource scenarios.

Slow and render-blocking resources

Years ago, I worked in an ecommerce startup and we were serving ad banners via an external provider. It was a quick solution to receive click statistics while providing marketers with a comfortable way to handle images on the site.

The banners were implemented with synchronous script elements above the fold.

<script type="text/javascript" src="http://some-provider.js"></script>

And we had plenty of these elements embedded in a slideshow. The scripts would load and replace containers with content coming from elsewhere. It worked beautifully… until it didn’t.

A synchronous script element stops the HTML parser and forces it to wait for the script to be downloaded and executed. The browser only continues parsing and rendering once this is done so that this script resulting in an embedded image can literally block anything on your site.

And that’s what exactly happened to me back in the day.

The script was loaded fairly quickly from Berlin, Germany and we didn’t notice any delays in rendering. But one day our third-party vendor experienced an outage. And interestingly, requests wouldn’t fail but just hang and time out eventually.

The result: a browser started rendering our site, stopped at the slideshow and waited for the scripts to time out. Our customers were looking at a white page until this happened and our site was entirely broken. A third-party vendor brought our frontend down because we implemented synchronous scripts. Be aware that every external dependency is another risk for your sites!

That’s why it’s generally better to self-host your assets and avoid critical render-blocking elements. No matter if you’re using ad tech, error monitoring scripts, or external stylesheets, make sure to double-check what happens when these resources fail. I doubt you want your system to be affected because of someone else's downtime.

That’s not the only situation where third-party resources can lead to trouble, though. Let’s come back to Chris’ example.

Tightly coupled JavaScript dependencies

Chris mentioned that he experiences broken sites on a regular basis. Some sites would fail in essential situations like making an order. The culprit: a thrown JavaScript exception.

That’s interesting because it’s unlikely that web developers aren’t testing their most important functionality. So what’s happening?

If you’re an ad blocker user there’s a high chance that this tiny browser extension is the reason. And that’s not the ad blocker’s fault. It’s doing what it’s supposed to do — blocking trackers (most likely third-party scripts). But the issue is often that developers expect these scripts to be loaded. For example, if your website’s JavaScript expects a sendTracking method to be available in the global window object, an ad blocker can easily mess with the site and cause JavaScript to fall on its nose.

Here’s Chris’ example:

// https://tracking-website.com/tracking-script.js
window.trackThing = function() {
  // report data
}

// /script/index.js
function init() {
  // this throws an exception if `tracking-script.js` was blocked
  trackThing("page loaded or something");
}
init();

If tracking-script.js fails or is blocked by a browser extension your code throws an exception and could blow up your entire app. If you’re implementing external JavaScript functionality, you should make sure that things are still functional in error cases because I bet you prefer processing an order over tracking it.

But how can you go around these two problems and guarantee that you won’t be running into frontend downtimes based on synchronous resources or “death by ad blocker” scenarios in the future?

How to test and monitor risky third-party resources with Playwright

Let’s take a simple HTML example running on my localhost:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Frontend downtime</title>
  <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha1/dist/css/bootstrap.min.css" rel="stylesheet"
integrity="sha384-GLhlTQ8iRABdZLl6O3oVMWSktQOp6b7In1Zl3/Jr59b6EGGoI1aFkw7cmDA6j6gD" crossorigin="anonymous">
</head>
<body>
  <h1>Hello world</h1>
  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha1/dist/js/bootstrap.bundle.min.js"
integrity="sha384-w76AqPfDkMBDXo30jS1Sgez6pr3x5MlQ1ZAGC+nuZB+EYdgRZgiwxhTBTkF7CXvN"
crossorigin="anonymous"></script>
  <script>bootstrap.Alert.getOrCreateInstance('#myAlert')</script>
</body>
</html>

It includes Bootstrap’s CSS and JavaScript, renders the headline “Hello world” and tries to access bootstrap.Alert which is available in the global window scope.

Note that in this case, both external resources are render-blocking. The stylesheet has to be loaded before anything appears on the screen and even though the script is placed at the end of the document, it will still block rendering (there’s just nothing to render after it).

A quick Playwright test for this page could look like this:

// @ts-check
const { test, expect } = require("@playwright/test")

test("has the correct title", async ({ page }) => {
  await page.goto("http://localhost:8080")

  // evaluate the largest contentful paint
  const largestContentfulPaint = await page.evaluate(() => {
    return new Promise((resolve) => {
      new PerformanceObserver((l) => {
        const entries = l.getEntries()
        // the last entry is the largest contentful paint
        const largestPaintEntry = entries.at(-1)
        resolve(largestPaintEntry.startTime)
      }).observe({
        type: "largest-contentful-paint",
        buffered: true,
      })
    })
  })

  console.log(parseFloat(largestContentfulPaint))

  await expect(page).toHaveTitle(/Frontend downtime/)
})

Playwright navigates to localhost and evaluates the popular largest contentful paint metric by injecting custom JavaScript into the page. When you run the script with npx playwright test you’ll see the following in your terminal:

Running 1 test using 1 worker
[chromium] › example.spec.js:4:1 › has the correct title
CLP: 116.39999999850988ms

1 passed (837ms)

Wonderful! The largest contentful paint is a hundred milliseconds long and everything works. But what if the Bootstrap resources on jsdeliver.net are slow to respond?

How to emulate slow third-party resources with Playwright

Let’s find out and delay requests by ten seconds that aren’t fetching resources from the same origin with Playwright’s page.route method.

// @ts-check
const { test, expect } = require("@playwright/test")

test("works with slows resources", async ({ page }) => {
  page.route(
    "**",
    (route) =>
      new Promise((resolve) => {
        const requestURL = route.request().url()

        if (requestURL.match(/http:\/\/localhost:8080/)) {
          resolve(route.continue())
        } else {
          setTimeout(() => {
            console.log(`Delaying ${requestURL}`)
            resolve(route.continue())
          }, 10000)
        }
      })
  )
  await page.goto("http://localhost:8080")

  const largestContentfulPaint = await page.evaluate(() => {
    return new Promise((resolve) => {
      new PerformanceObserver((l) => {
        const entries = l.getEntries()
        // the last entry is the largest contentful paint
        const largestPaintEntry = entries.at(-1)
        resolve(largestPaintEntry.startTime)
      }).observe({
        type: "largest-contentful-paint",
        buffered: true,
      })
    })
  })

  console.log(`CLP: ${parseFloat(largestContentfulPaint)}ms`)

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Frontend downtime/)
})

The test still passes but its test duration skyrocketed from 800ms to 10 seconds and similarly, the largest contentful paint also joined at the ten seconds mark.

Running 1 test using 1 worker
[chromium] › example.spec.js:4:1 › has the correct title
Delaying https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha1/dist/css/bootstrap.min.css
Delaying https://cdn.jsdelivr.net/npm/bootstrap@5.3.0-alpha1/dist/js/bootstrap.bundle.min.js

CLP: 10186.10000000149ms

1 passed (11.0s)

What is going on? Let’s create a Playwright trace and debug this test.

There are two things to note in this Playwright trace: first, the test duration increased to ten seconds because Playwright’s page.goto waits for the page onload event which is heavily delayed by the slowed-down stylesheet.

And second, and probably worse than a slow test case, the user experience suffered tremendously because the page only started rendering after ten seconds.

After running a quick Playwright test, you now know that there are 3rd party resources that could really harm your overall performance and you can check if they’re necessary or if you should implement them in another way.

But what if these requests fail or are blocked by browser extensions?

How to block requests with Playwright

So far we’ve only been delaying third-party resources, but what happens when we block them entirely? Luckily, blocking resources is quickly done with page.route, too.

test("works with blocked 3rd party resources", async ({ page }) => {
  page.route("**", (route) => {
    const requestURL = route.request().url()

    if (requestURL.match(/http:\/\/localhost:8080/)) {
      route.continue()
    } else {
      route.abort()
    }
  })

  // monitor emitted page errors
  const errors = []
  page.on("pageerror", (error) => {
    errors.push(error)
  })

  await page.goto("http://localhost:8080")

  console.log(errors)
  expect(errors.length).toBe(0)
})

If you run the script the test case fails because the page emits pageerrors. The inline JavaScript tried to call a Bootstrap method that wasn’t available because of resource blocking similar to how an ad blocker would do it.

Running 1 tests using 1 workers
[chromium] › example.spec.js:43:1 › works with blocked 3rd party resources
[
  Error [ReferenceError]: bootstrap is not defined at http://localhost:8080/:18:11
]
1) [chromium] › example.spec.js:43:1 › works with blocked 3rd party resources ====================

Error: expect(received).toBe(expected) // Object.is equality
    Expected: 0
    Received: 1

    60 |
    61 |   console.log(errors)
  > 62 |   expect(errors.length).toBe(0)
       |                         ^
    63 | })
    64 |

Tracking page errors is a handy way to monitor your JavaScript in a synthetic lab setup. In the case of ad blockers and canceled requests, you could still perform your end-to-end tests and evaluate if a blocked script affects your site at all.

Either way, page.route is an easy-to-use way to emulate network conditions with Playwright.

So what’s next?

Here’s the takeaway: whenever you implement and rely on resources you don’t control, make sure that they’re not affecting or blowing up your application! People use browser extensions, networks are flaky, services go down… many things that can go wrong.

Know how your app handles slow responses or requests that might become victims of ad blockers.

Note: This post’s code snippets implement page request handling on a test-case basis for simplicity. I recommend looking into Playwright’s fixtures to not clutter your tests and focus on your end-to-end logic. Work with a nicely abstracted pageWithSlowThirdParties object instead!

But how should you go about these two scenarios then? Should you run all your deployment end-to-end tests with changed third-party network settings?

Frontend testing vs. monitoring

End-to-end testing with resource constraints is a great step to gain confidence and guarantee that your deployed code works no matter if your dependencies are slow or unavailable. But honestly, testing end-to-end is only the first step to real confidence because between today’s deployment and tomorrow plenty of other things can go wrong.

While end-to-end testing guarantees that your site works at one moment in time and helps to evaluate regressions in your source code, if you’re relying on third-party resources, your third-party provider’s downtime can still affect your site. And that’s sometimes unavoidable but at least, you should be aware of your dependencies’ effects on your site and bet on end-to-end monitoring. Be the first one to know when your vendors are struggling!

Conclusion

First, if you’re relying on resources that you don’t own, check how their unavailability could affect your frontend. Opt for self-hosting your assets, and if that’s impossible, rely on asynchronous and fail-safe implementations.

Second, test your site during deployments and stop, if new and risky dependencies were added to your frontend. A script element pointing to another CDN is quickly implemented. Be aware of your external resources and how they affect your application.

And third, if you have to rely on external resources, start monitoring your frontend, run your end-to-end tests on a schedule, and ensure that your site—and also those external resources!—are up and running. Don’t be me, coming to work only to learn that your customers have been looking at a blank screen 30 seconds long for the last 8 hours.

And maybe you want to give Checkly a try, we’ll run your Playwright tests for you. 😉

Playwright Tips From the Checkly Community

Stefan Judis — Wed, 01 Feb 2023 12:38:26 +0000

The Checkly community recently came together to talk Playwright in our public Slack! My fellow Playwright ambassador John Hill and I invited everyone to ask questions and share tips about Microsoft’s stellar end-to-end testing tool.

And there were plenty of them! Let’s have a look at my favorite questions (and learnings) coming from the community! Are you ready for a mixed bag of Playwright tricks? Let’s go!

How should you handle parallelism in your end-to-end tests?

In general, it’s best practice to parallelize as many tests as possible to avoid seeing your test duration going through the roof. No one likes to wait thirty minutes for a green deployment light and a test suite that takes forever (or flakiness) is the main reason your test efforts fail.

But as usual in software development, things are complicated and every complex project comes with its own challenges when it comes to testing.

A tricky case is test cases that involve resource updates. If all your tests run in parallel it’s easy to discover race conditions where one test creates or deletes a resource while another one is testing it, too! This problem is tricky to solve and there is no ideal solution but our CTO Tim Nolet shared a possible approach:

For non-destructive tests that are not relying on a state in your database, Tim recommends going all in with parallel testing. Your test cases could range from checking that a modal pops up after a button click or previews that are rendered when someone interacts with a text field. All these tests can run independently and in parallel.

With stateful tests, it’s a different story, though. If resource creation and updates are at play, it’s sometimes unavoidable to run tests sequentially to avoid one test messing with another one.

But how do you separate and run these different tests in your Playwright project?

To implement Tim’s recommendation in your project, you have to familiarize yourself with how Playwright handles parallelism.

In general, Playwright runs different test files in parallel, and all tests in a file are run sequentially. But watch out, the fullyParallel global config changes this behavior and runs every test case in parallel regardless of where it’s defined.

The default behavior lets you run tests that are in a single file sequential. For example, if you want to create, update and delete resources after another, having tests in a single file guarantees execution order.

That’s a good start, but unfortunately, it doesn’t guarantee that other spec files aren’t interfering with a similar resource and this again could lead to false positives. Luckily Playwright is highly configurable and you can disable parallelism via the CLI or Playwright config by defining the number of workers running your tests.

npx playwright test --workers=1

The global workers configuration enables you to run tests with different parallelization settings. Independent and stateless tests can be run fully parallel whereas sequential state-dependent tests can run in a sequence.

To split tests, leverage custom annotations or file path conventions to run Playwright in full parallelized or sequential mode. The example package.json below leverages different directories to separate parallel from sequential test cases.

{
  "name": "parallel",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test:parallel": "npx playwright test tests/parallel/",
    "test:sequence": "npx playwright test tests/sequence/ --workers=1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@playwright/test": "^1.29.2"
  }
}

With this setup, you can run npm run test:parallel and npm run:sequence without running into test conflicts. By separating the stateless and stateful tests, you’ll be able to reduce test collisions and run independent tests as quickly as possible.

But end-to-end tests that interact with the same resources are only one cause for flakiness. There are plenty of others!

What are common reasons for flaky tests and how can you avoid them?

There are many reasons for flaky tests. Giovanni Rago, our Head of Customer Solutions, shared his top flakiness offenders.

As Gio states, suboptimal waiting is a common problem in UI and end-to-end testing.

To test your application it has to have reached a particular state, JavaScript probably needs to be loaded or potential API calls had to resolve. There are multiple ways to go about testing your UIs.

But before going into explicit waiting scenarios, make sure to check Playwright’s auto-waiting mechanisms and web-first assertions. With all the built-in auto-waiting mechanisms you rarely need to worry about explicit waiting. For example, if you want to test a UI flow that includes a component that only becomes visible eventually, Playwright actions such as click wait for elements to become visible.

These features enable you to test highly asynchronous UIs with code that looks synchronous.

// Playwright retries to click this button until it works or times out
await page.getByRole('button').click();

But as Gio says, sometimes these built-in waiting mechanisms aren’t enough and you have to wait for an explicit event to happen or a UI state to be reached. John Hill takes things to another level and recommends watching specific network requests to make functionality deterministic.

If you click a button, that triggers an API call, you can wait for the API call to resolve and test if the UI reacted accordingly.

As John states:

If your browser has a HTTP API Backend, the #1 way to add determinism to your tests is to wait on the specific network requests to resolve.
99% of the flake I’ve experienced when testing a flaky frontend app comes from a flaky and unreliable backend.
The frontend tests are just the bearer of bad news.

If you want to check an example of this approach, here’s the code John and the team at Open MCT run to test UIs request-dependent at Nasa.

How can you emulate custom keyboard interactions in Playwright?

If you’re working on a SaaS product and aim for stellar UX, you might implement keyboard shortcuts and interactions. These could be challenging to test, but luckily, Playwright also supports a way to control a virtual keyboard.

Playwright’s keyboard functionality enables you to interact with input elements and pages like a real user.

await page.keyboard.press("Meta+KeyA")
await page.keyboard.type('This is a line of text\n');

This functionality is great for shortcuts but also valuable for highly custom and complex components. One example is a JS-based code editor like Monaco.

Millions of developers use Monaco because it’s built into VS Code (and app.checklyhq.com 😉). But how does it work under the hood and how would you test a custom editor if it’s embedded in your application?

Open the Monaco Playground to look at Microsoft’s open-source editor component. When you inspect the editor, you’ll see that to offer syntax highlighting, there are divs and spans all over the editor component. But how could you edit and test these and interact with the editor?

Monaco and other code editor components usually include a hidden or transparent textarea to catch keyboard events and make things more accessible. The textarea keystrokes are captured, canvas elements render code suggestions, and spans/divs display highlighted code. There’s a lot of magic involved and it’s pretty challenging to test.

Luckily, Playwright’s virtual keyboard helps out here and as the Playwright core team member Max Schmitt shared, page.keyboard is at your service to interact with Monaco.

await page.goto('https://microsoft.github.io/monaco-editor/playground.html');
const monacoEditor = page.locator(".monaco-editor").nth(0);
await monacoEditor.click();
await page.keyboard.press("Meta+KeyA");
await page.keyboard.type('This is a line of text\n');
await page.screenshot({ path: example.png });

This functionality allows testing and simulating keyboard interactions going beyond filling an input with a string value. Press specific key combinations, jump to the beginning of a line, or hit the “delete” key three times… It’s up to you to mimic your users’ keyboard behavior!

Related Reading: How we added custom languages, code completion and highlighting to the Monaco editor.

Real users are an unpredictable bunch, though. How can you guarantee that your application isn’t breaking when you “attack” it with your end-to-end tests?

How can you catch JavaScript errors in long end-to-end testing flows?

It’s always good to monitor if your application throws JavaScript exceptions when users interact with it. Luckily, reacting to JavaScript errors is straightforward in Playwright by leveraging emitted page events such as pageerror. React and count exceptions with a few lines of code.

// Log all uncaught errors to the terminal
page.on('pageerror', exception => {
  console.log(`Uncaught exception: "${exception}"`);
});

Related video: if you want to learn how these work, have a look at one of our Playwright tips on YouTube.

John Hill again puts things to the next level and shared how they implement JavaScript error tracking with Playwright fixtures. His approach allows you to collect all JS errors until the end of your test and only fail it then.

exports.test = base.test.extend({
   failOnConsoleError: [true, { option: true }],
   /**
    * Extends the base page class to enable console log error detection.
    * @see {@link https://github.com/microsoft/playwright/discussions/11690 Github Discussion}
    */
   page: async ({ page, failOnConsoleError }, use) => {
       // Capture any console errors during test execution
       const messages = [];
       page.on('console', (msg) => messages.push(msg));
       await use(page);

       // Assert against console errors during teardown
       if (failOnConsoleError) {
           messages.forEach(
               msg => expect.soft(msg.type(), `Console error detected: ${_consoleMessageToString(msg)}`).not.toEqual('error')
           );
       }
   }
});

The example leverages fixtures and soft assertions and if you’re curious, have a look at John’s provided example code.

Conclusion

These were my favorite Playwright learnings from our Community AMA session and I continue to be amazed at how far end-to-end testing has come. If you want to keep learning about Playwright, check out our Checkly YouTube channel where I share all these nitty-gritty tricks as I discover them. And if you have any questions, don’t hesitate to drop into Slack, I’m happy to help!

And lastly, you might know that testing is only the beginning of shipping stellar products. If you want to start monitoring your apps and be confident that your site works at all times, this is what we do at Checkly. Sign up and run Playwright tests at any time from around the world. It’s free and pretty cool, trust me! 😉

TIL — Why Custom properties don't work with the url() CSS function

Stefan Judis — Fri, 23 Sep 2022 18:48:20 +0000

Custom properties and CSS parsing are always good for surprises like !important behaving slightly differently or properties being "invalid at computed value time".

Today I discovered yet another surprise — custom properties don't work in combination with the url() function. 😲

.something {
  /* this doesn't work */
  --image: https://jo.com/image.jpg;
  background: url(var(--image));
}

Roman Dvornov describes the details quite well in a GitHub issue, but let me give you a condensed explanation.

The two modes of `url()`

Your url()-containing CSS will be parsed differently, depending on how you use url(). There's an old and a newer way:

Old: url(https://jo.com/image.jpg)
Newer: url('https://jo.com/image.jpg') or url("https://jo.com/image.jpg")

The problem of the legacy `url()` token

And these missing quotes of the old way might seem like a tiny detail, but they affect how your CSS is parsed.

Without quotes, the url() syntax looks like a CSS function, but it isn't. CSS parsers will treat it as a single token, as so-called url-token.

.something {
  background: url(https://ja.com/image.jpg);
  //          \---------------------------/
  //            without quotes this ☝️ is
  //               a single CSS token
}

And this entire token from url( to the closing ) enforces parentheses, whitespace characters, single quotes (') and double quotes (") to be escaped with a backslash.

url() with a quoted string, on the other hand, is a normal and flexible CSS function notation, which is parsed part by part and works as expected.

But now, guess what happens when you want to use a custom property in combination with url()?

.something {
  /* this doesn't work */
  --image: https://jo.com/image.jpg;
  background: url(var(--image));
//                ☝️ "No quotes? Cool, that's a url-token!"
//                😢 "Too bad though, `(` isn't allowed in here..."
//                ❌ "I'll throw everything away!"
}

Because there are no quotes, this declaration is parsed as a url-token. And unfortunately, the ( in var(--image) isn't escaped, so the parser throws an error and invalidates the entire CSS declaration.

And this legacy url-token parsing is why you can't use custom variables inside of url().

The solution to work around the legacy `url()`

What's the usual solution, when there's a problem with old web legacy? It's inventing new stuff because we can't break the web and just change things.

To enable custom properties in url() there's a new alias in town. The src() notation behaves the same way as url() but without this weird legacy url-token logic.

.something {
  /* this works! (theoretically) */
  --image: https://jo.com/image.jpg;
  background: src(var(--image));
}

Problem solved! But yet, no browser supports src() (I couldn't find browser support information but tested current Chrome, Safari and Firefox), so it's time for us to wait. 🤷‍♂️

CSS parsing and custom properties — always good for a surprise!

If you want to read more about this topic, here are some resources:

DEV Community: Stefan Judis

Web Weekly 171 — ::details-content goes baseline, the `closed-by` attribute, and `field-sizing: content`.

Guten Tag! Guten Tag! 👋

Something that made me smile this week

No code

Are editor themes too "loud"?

closed-by=any

When the virtual keyboard messes with your viewport

header and footer elements change their roles

The wonderful weird web – spurious correlations

field-sizing works for input and select elements, too!

25 CSS you should know

Is AI really saving time?

More perf metrics in more browsers!

Yet another CSS reset

Random MDN – Object.freeze()

New on the baseline

Three valuable projects to have a look at

A new Tiny Helper

Thought of the week

Do you enjoy Web Weekly? | Did you learn something from this issue?

This is all, friends!

Header and footer elements lose their roles in sectioning content

Creating Animated Accordions with the Details Element and Modern CSS

Generating markup from your design

The base setup

Removing the details default styling

Connecting multiple details to build an exclusive accordion

Animating the details content

::details-content — the expandable/collapsible details content

Animating height with interpolate-size

Transitioning properties like display or content-visibility with transition-behavior

Reacting to DOM changes with the :has() selector

Conclusion

Stefan Judis

🧢 Web Weekly newsletter 152 — Interop 2025, console.context() and Number.POSITIVE_INFINITY

Guten Tag! Guten Tag! 👋

Something that made me smile this week

New on the blog

Let's stop using animated gifs

LCP !== LCP

Why we should consider searchability

console.context()

The wonderful weird web – Floor796

Is AI hindering new tech adoption?

Speculation rules on google.com

A 💙 for CSS grid

A massive Node.js ecosystem update

Random MDN – Number.POSITIVE_INFINITY

TIL recap – media query boolean contexts

New on the baseline — Styling scrollbars

Three valuable projects to have a look at

A new Tiny Helper

Thought of the week

Did you learn something from this issue?

This is all, friends!

🧢 Web Weekly 151 — `popover` enters the baseline!

Guten Tag! Guten Tag! 👋

Something that made me smile this week

New on the blog

The European Accessibility Act (EAA)

On native CSS nesting

It's about people

How to favicon in 2025

The wonderful weird web – Stripe's Black Friday stats

Replace your animation libs with startViewTransition()

Get started with MPA view transitions

Managing focus

Some WebDev Trivia...

How to start a blog

Random MDN – :user-valid / :user-invalid

TIL recap – table caption

New on the baseline — popover

Classifieds & friends

Three valuable projects to have a look at

A new Tiny Helper

Thought of the week

Did you learn something from this issue?

This is all, friends!

Replace your JavaScript Animation Library with View Transitions

`closed-by=any`

`header` and `footer` elements change their roles

`field-sizing` works for `input` and `select` elements, too!

Random MDN – `Object.freeze()`

Removing the `details` default styling

Connecting multiple `details` to build an exclusive accordion

Animating the `details` content

`::details-content` — the expandable/collapsible `details` content

Animating height with `interpolate-size`

Transitioning properties like `display` or `content-visibility` with `transition-behavior`

Reacting to DOM changes with the `:has()` selector

`console.context()`

Speculation rules on `google.com`

Random MDN – `Number.POSITIVE_INFINITY`

Replace your animation libs with `startViewTransition()`

Random MDN – `:user-valid` / `:user-invalid`

TIL recap – table `caption`

New on the baseline — `popover`

Use `view-transition-name` to animate elements separately

Applying `z-index` to separate view transitions

Sliding the hero image over the text with `position: sticky`

Animating the hero element on scroll progress (`scroll()`)

Animating the hero element on view progress (`view()`)

The two modes of `url()`

The problem of the legacy `url()` token

The solution to work around the legacy `url()`