Frontend Masters Boost RSS Feed

View Transitions Feature Explorer

Chris Coyier — Thu, 30 Oct 2025 23:58:40 +0000

It’s a generally good thing to know that browser support for browser features isn’t always quite a simple as yes or no. There can be sub-features involved as things evolve that roll out in browsers at different times. View Transitions is an example of that going on right now. There are “Same-Document View Transitions” supported in all browsers right now, but “Cross-Document View Transitions” are still missing Firefox support. And there are quite a few more related features beyond that! Bramus has a nice way to explore that.

CodePen Embed Fallback

View Transition List Reordering (with a Kick Flip)

Chris Coyier — Tue, 08 Jul 2025 16:10:25 +0000

I remember when we first got animations and transitions in CSS on the web (ok grandpa), the talk around it was balanced between oooo! fun! shiny! and actually, movement is more than aesthetics; it can help people understand what is happening in user interfaces.

The example that got stuck in my head was reordering lists. Imagine a single list item being plucked off and moved to the top. If that instantly happens, it can be hard to catch what even happened. But if you animate the movement, it can be extremely obvious what is happening.

Works, but it is not particularly easy to understand what is happening:

More fun and easier to understand what is happening:

The List

We’re talking a regular ol list. Perhaps ironic that we’re ordering and unordered lists, but I’ll leave that as a semantic thoughtworm for the reader.

Each list item has text, then a button which the intended action is that, when clicked, will move the list item to the top.

<ul class="list">
  <li>
    Apples
    <button hidden disabled aria-label="Move to Top">
      <svg ...>svg>
    button>
  li>
  <li>
    Oranges
    <button hidden disabled aria-label="Move to Top">
      <svg ...>svg>
    button>
  li>
  <li>
    <button hidden disabled aria-label="Move to Top">
      <svg ...>svg>
    button>
    Mangos
  li>
  <li>
    <button hidden disabled aria-label="Move to Top">
      <svg ...>svg>
    button>
    Bananas
  li>
ul>

Note that each button has a text label (as we’re not using text inside the button), and a hidden attribute we’ll use to make sure the button isn’t there at all when JavaScript is disabled.

Scaffolding the Interactive JavaScript

This will get us references to the elements we need, as well as do a loop and un-hide the buttons as well as attach an event listener to them:

const button = document.querySelector("button");
const list = document.querySelector(".list");
let listItems = list.querySelectorAll("li");
const listItemButtons = list.querySelectorAll("li > button");

listItemButtons.forEach((button) => {
  button.hidden = false;
  button.addEventListener("click", async () => {
    // do stuff
  });
});

Moving the List Item to the Top

When the button is clicked, we’ll need the list item, not the button itself, so we reach up a level to the parent. Then we freshly figure out what the first list item is, and insertBefore it, making the clicked one the first one.

const button = document.querySelector("button");
const list = document.querySelector(".list");
let listItems = list.querySelectorAll("li");
const listItemButtons = list.querySelectorAll("li > button");

listItemButtons.forEach((button) => {
  button.hidden = false;
  button.addEventListener("click", async () => {
    const item = button.parentElement;
    const firstListItem = list.querySelector(".list :first-child");
    list.insertBefore(item, firstListItem);

    // This is probably the better API to use, but less supported...
    // list.moveBefore(item, firstListItem);
  });
});

I only recently learned about moveBefore which is probably a better API to use, but we can wait a bit for better support.

(Progressively Enhanced) Movement via View Transitions

One type of View Transitions are “same page” View Transitions, where we essentially call document.startViewTransition and change the DOM inside the callback.

const button = document.querySelector("button");
const list = document.querySelector(".list");
let listItems = list.querySelectorAll("li");
const listItemButtons = list.querySelectorAll("li > button");

function moveListItemFirst(item) {
  const firstListItem = list.querySelector(".list :first-child");
  list.insertBefore(item, firstListItem);
}

listItemButtons.forEach((button) => {
  button.hidden = false;
  button.addEventListener("click", async () => {
    const item = button.parentElement;
    if (document.startViewTransition) {
      const transition = document.startViewTransition(() => {
        moveListItemFirst(item);
      });
    } else {
      moveListItemFirst(item);
    }
  });
});

Because we need to move the list item whether the browser supports View Transitions or not, we abstract that to a function, and call it on either branch of logic testing that support.

This will immediately do a fade transition for the list items, which honestly isn’t much of an improvement in this case (it still can be nice for the other type of View Transitions: page transitions). Fortunately, we’ve got a pretty decent one-line fix in CSS:

ul {
  li {
    view-transition-name: match-element;
  }
}

If you’ve played with View Transitions before, it’s likely you’ve got in your head that every single element needs a unique view-transition-name. And that’s still true in Firefox for now, as only Chrome and Safari are supporting match-element as I write. But as we’re just playing here, this is such a nice improvement and reduces so much fiddliness, I think it’s worth it.

Special View Transitions Only For the “Main Moving Element”

The deal here is really that all the elements are moving. It’s either the element you clicked on moving to the first position, or the rest of the list items moving out of the way.

So the goal here is to apply a unique view-transition-name to the element that is the “main moving element”, then remove it once it’s done. To make matters a bit more difficult, we’ve got two animations we want to apply, one of the list item, and one just for the icon within the button. That’s slightly tricky!

const button = document.querySelector("button");
const list = document.querySelector(".list");
let listItems = list.querySelectorAll("li");
const listItemButtons = list.querySelectorAll("li > button");

function moveListItemFirst(item) {
  const firstListItem = list.querySelector(".list :first-child");
  list.insertBefore(item, firstListItem);
}

listItemButtons.forEach((button) => {
  button.hidden = false;
  button.addEventListener("click", async () => {
    const item = button.parentElement;

    item.style.viewTransitionName = "woosh";
    item.querySelector("svg").style.viewTransitionName = "tony-hawk";

    if (document.startViewTransition) {
      const transition = document.startViewTransition(() => {
        moveListItemFirst(item);
      });

      try {
        await transition.finished;
      } finally {
        item.style.viewTransitionName = "";
        item.querySelector("svg").style.viewTransitionName = "";
        makeFirstListItemsButtonDisabled();
      }
    } else {
      moveListItemFirst(item);
    }
  });
});

Now we’ve got “woosh” and “tony-hawk” view transition names we can use to apply animation control in CSS.

::view-transition-group(*) {
  animation-duration: 1s;
}

::view-transition-old(woosh),
::view-transition-new(woosh) {
  animation: woosh 1s ease-in-out;
}

@keyframes woosh {
  50% {
    translate: -100px 0;
    scale: 1.5;
    box-shadow: 0 30px 15px lch(0% 0 0 / 50%);
  }
}

::view-transition-old(tony-hawk),
::view-transition-new(tony-hawk) {
  animation: tony-hawk 1s ease-in-out;
}

@keyframes tony-hawk {
  /* sick kick flip */
  50% {
    rotate: 20deg;
    scale: 2.5;
  }
}

So for the “non-main” elements, they just move up and down over 1s. But for the “main” moving element, we’ve got these unique @keyframe animations we apply while the re-ordering is happening. Note that the keyframes are only applying the 50% keyframe, so they animate from wherever they were to wherever they are going still, just in the middle they do something special, like the sick kick flip.

Demo

CodePen Embed Fallback

Video

I’m playing with streaming and this idea started as a loose idea for a stream, then I lightly edited it for a regular YouTube video, so maybe you’d enjoy that:

Relatively New Things You Should Know about HTML Heading Into 2025

Chris Coyier — Mon, 06 Jan 2025 15:42:42 +0000

Not all of this is like absolutely brand spanking new just-dropped-in-2024 stuff. Some of it is, but generally it’s relatively new stuff that’s all pretty great. I’m pointing things out that I think are really worth knowing about. It’s possible you haven’t kept up too much with HTML developments as it tends to, rightfully, move a lot slower than CSS or JavaScript.

A group of details elements can behave like an accordion, among other improvements, but still have accessibility limitations.

We’ve had cross-browser

support since 2016, but only recently have the abilities started to expand and clean up.

For one, you can make an “exclusive” accordion by grouping them together via the name attribute:

<details name="group"><summary>Onesummary> ... details>
<details name="group"><summary>Atsummary> ... details>
<details name="group"><summary>Asummary> ... details>
<details name="group"><summary>Timesummary> ... details>

Me, I mostly think the only-one-open-at-a-time thing is an anti-pattern (as do others), mostly because it’s weird to close something a user may have intentionally opened via side effect. But the web is a big place and certain specific designs I can see needing it to be effective so I don’t hate that it exists. At least I think using the term “accordion” is now appropriate in this context, but that there are still potential accessibility issues. Like imagine using this for a FAQ section where each question would normally be a header like

, well, the semantics of that

is wiped out by the

, which is a “button”, so that’s not great.

Here’s an example of the accordion pattern being used with a group of horizontally laid out details elements. If more could be opened, it could cause horizontal scroll which I sure we can all imagine also sucks.

CodePen Embed Fallback

Note that those

elements are in a flexbox layout and are themselves display: flex; and only recently has that improved. (See Stephanie Stimac’s article on recent improvements.)

Ya know how the inside of a

is:

… and whatever else

The “whatever else” can be one or more elements, and there isn’t any particularly clean way of selecting them. This is a CSS thing, but now we’ve got a ::details-content pseudo-element selector to get our hands on all that HTML in case it needs similar treatment (imagine fading it all in or out).

Here’s a great demo of using that, as well as other brand new CSS features, to make honest-to-god animating open/close details elements with arbitrary content in just HTML and CSS.

CodePen Embed Fallback

Styleable Selects are Coming

Browsers can’t just all the sudden make every aspect of a pretty freely, opening up huge doors to designing that experience.

There is some other funky things to know so I’d suggest reading this whole article. Even some new (tricky) HTML!

<select class="country-select">
  <button>
    <selectedoption>selectedoption>
  button>
  <option value="" hidden>
    <figure>figure>
    <span>Select a countryspan>
  option>
  <option value="andorra">
    <img src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/19/Flag_of_Andorra.svg/120px-Flag_of_Andorra.svg.png" alt="" />
    <span>Andorraspan>
  option>
  ...
select>

My favorite episode of Off the Main Thread this year was about styleable selects and all the interesting details behind them that will have knock-on effects.

Oh — also you can slap a line into a select menu

I kinda love how the old school name attribute was used with

for the accordion behavior.

And speaking of old school elements, you can put an

within a