Transition on an active highlight - it's not as simple as it seems

[9am]

After fixing a bug, I found that to achieve this on the web takes more effort than I expected. However, the new view transition API offers a straightforward solution.

[9am]

Table of contents

• Preface
• The problem
• A simple case
  • What if it's a 2-dimensional layout
  • What if the items have different sizes
  • What if the container resized
  • What if the active item resized
  • What if the sibling of the active item resized
  • What if items reordered
• The universal solution
• New option: view transition API

Preface ␥

A couple of weeks ago, a bug was reported about a React component owned by my team, which is a ToggleButton that works like the native <input type="radio"> group. Except that a colored highlight will follow the active item with a transition effect as the users select.

The bug is:

The highlight does not resize and reposition when textContent changes happen on the active item.

Well, the cause is the original implementation of the active highlight:

1. To make it transition as UE wanted, it needs to be a separate element with the same size and position as the active item.
2. It renders the new size and position when the active item changes, which will cover most cases but not DOM mutation.

After digging a little bit deeper, I found that a universal solution is harder than I thought.

𐄡

The problem ␥

Let's look at what we're dealing with:

1. For a source element (A) in any layout on the web page, create a highlight element (B) that follows the size and position of (A) no matter how the page changes.
2. If the source switches from (A) to (C), (B) will switch source accordingly.

It can be split into 3 questions:

1. Where to put the highlight?
2. How to get the new position and size of the source?
3. When to trigger rerender?

𐄡

A simple case ␥

To answer those questions, let's start with a simple case.

Here we have a horizontal flex layout of items with the same sizes.

1, Where to put the highlight?

To make it transition, we can add a new element(or pseudo-elements) in the container and make it position: absolute, so that changes outside container can not affect how it is positioned.

<ul class="container">
  <li class="item">item 1</li>
  <!-- ...other items -->
  <li class="highlight"></li>
</ul>

2, How to get the new position and size of the source?

Since it's an even-size horizontal layout, we can calculate the width of the active item with 100% / var(--item-num). (gap not included)

As for the position, just translate across xAxis by var(--width) * var(--item-active)). (gap not included)

3, When to trigger rerender?

The moment the number of items or the active item changes, we need to update the highlight.

Put them together:

live demo

The example is in plain html/css/javascript to demonstrate the case. For React, there are other problems to solve.

But the solution is not perfect. There are a bunch of edge cases to consider:

1. What if it's a 2-dimensional layout? ␥

For the size & position, we need to include height and translateY for vertical alignment to make it work. Additionally, the total column number for the layout is mandatory to do the math.

2. What if the items have different sizes? ␥

Apparently, we can no longer get the size by the percentage which leaves us no choice but to use clientWidth & clientHeight.

As for the position, we can only rely on getClientBoundingRect() to calculate the offset position from the item to the container.

3. What if the container resized? ␥

Maybe it's triggered by users or maybe by parent layout changing or resizing of a sibling, anyway. that's possible. So the trigger of rerender should include a ResizeOberservor on the container.

4. What if the active item resized? ␥

The bug we encountered falls into this category. A lot of things can cause the item to resize: textContent changing, Adding or Removing childNodes, or just setting new width & height directly in the style. So the trigger of rerender should include a ResizeOberservor on the active item.

5. What if the sibling of the active item resized? ␥

Yes, it happens, and if the container has a fixed size, it can not be caught by the ResizeOberservor on the container.

6. What if items reordered? ␥

Well, it's not common, to cover those cases we have no choice but to add a MutationObserver on the container.

𐄡

The universal solution ␥

After asking those 'what ifs', I found myself end up trying to figure out how the browser layout elements and what triggers the layout change. So a once-for-all solution looks like this:

The final answers

1. Where to put the highlight?

   New Element or Pseudo Element.

2. How to get the new position and size of the source?

   getClientBoundingRect().

3. When to trigger rerender?

   container resize & mutate
   active item resize

live demo

And I created a custom React Hooks called use-spotlight for this kind of situation, which involves other problems to solve like the updating of active refs won't trigger a rerender, etc. Anyway I managed to do it, but the code gets more complicated.

I can't help but wonder: Does it need to be this hard to do a simple effect like this on the web? What is the missing block here?

𐄡

New option: view transition API ␥

Creating an element with the same size and position as another element is easy on the web. An absolute positioned 100% width height child will always follow the source. Why we have this solution above is that we couldn't do a transition between different elements. So we need to stick with 1 element and calculate the size and position manually.

The view transition API came up to smooth the transition experience for the SPA situation. But it definitely can do more. It brings transition between different elements to the web for the first time. Check this out:

codepen

Since the 'highlight' is a pseudo, even without the startViewTransition(), it will still be working as a 'fallback' version of 'highlight'. That's a wonderful way of treating 'transition' as an enhancement.

Note

This is an experimental technology
Check the Browser compatibility table carefully before using this in production.

𐄡

Closing thoughts

Web development evolved so fast for years and the trend is not slowing down. New things keep coming up about HTML/CSS/JS, frameworks, bundlers, etc... I'm coding in a way totally different from 5 years ago, even 1 year ago. In a way that's a good thing, but the concepts are getting more and more complicated. And one needs to learn a ton of knowledge ahead to start building something or understand what's happening behind the codes. I kind of miss the simplicity of the old-time web. At the end of the day, it's not technology that holds us back from sharing ideas.

Or maybe I'm just getting old -_-|||

---

@9am 🕘

• Read more articles at 9am.github.io
• Find other things I built on GitHub and NPM
• Contact me via email
•