Tag: Cases

Ahmad Shadeed: Use Cases For CSS fit-content

Ahmad Shadeed covers the CSS fit-content sizing keyword. It’s useful! It just doesn’t come up super often. I find myself using min-content a lot more, like when setting up the height of a grid-template-row.

The fit-content keyword is actually closely related to min-content and max-content — it just has a little heuristic it follows that Ahmad nicely illustrates as a flow chart.

Ahmad Shadeed's flow chat illustrating the way browsers handle the CSS fit-content keyword.
“Use Cases For CSS fit-content” by Ahmad Shadeed

My favorite use case is covered here: sizing a <figure> with fit-content, so that it neatly wraps around the <img>. That way, even if the image doesn’t fill the parent space, and it can remain block-level.

We also covered PPK’s deep dive on fit-content last year. One of the key takeaways for understanding it is knowing that is it essentially a shorthand way of writing:

.box {   width: fit-content;    /* ... is the same as ... */   width: auto;   min-width: min-content;   max-width: max-content; }

To Shared LinkPermalink on CSS-Tricks

Ahmad Shadeed: Use Cases For CSS fit-content originally published on CSS-Tricks. You should get the newsletter.


, , ,

Practical Use Cases for Scroll-Linked Animations in CSS with Scroll Timelines

The Scroll-Linked Animations specification is an upcoming and experimental addition to CSS. Using the @scroll-timeline at-rule and animation-timeline property this specification provides you can control the time position of regular CSS Animations by scrolling.

In this post, we take a look at some practical use cases where scroll-linked animations come in handy, replacing a typical JavaScript approach.

👨‍🔬 The CSS features described in this post are still experimental and not finalized at all. The are not supported by any browser at the time of writing, except for Chromium ≥ 89 with the #experimental-web-platform-features flag enabled.

CSS Scroll-Linked Animations, a quick primer

With CSS Scroll-Linked Animations, you can drive a CSS animation by scroll: as you scroll up or down inside a scroll container, the linked CSS animation will advance or rewind. Best of all is that this is all running off main thread, on the compositor.

You need three things to implement a basic scroll-linked animation:

  1. a CSS animation
  2. a scroll timeline
  3. a link between both

CSS animation

This is a regular CSS Animation like we already know:

@keyframes adjust-progressbar {   from {     transform: scaleX(0);   }   to {     transform: scaleX(1);   } }

As you normally do, attach it to an element using the animation property:

#progressbar {   animation: 1s linear forwards adjust-progressbar; }

Scroll timeline

The scroll timeline allows us to map the scroll distance to the animation progress. In CSS, we describe this with the CSS @scroll-timeline at-rule.

@scroll-timeline scroll-in-document-timeline {   source: auto;   orientation: vertical;   scroll-offsets: 0%, 100%; }

This at-rule consists of descriptors, including:

  1. The source describes the scrollable element whose scrolling triggers the activation and drives the progress of the timeline. By default, this is the entire document.
  2. The orientation determines the scrolling direction that should trigger the animation. By default, this is vertical.
  3. The scroll-offsets property is an array of key points that describe the range in which the animation should be active. It can be absolute values (e.g. percentages and lengths) or element-based.

A previous version of the specification required you to also set a time-range descriptor. This descriptor has been removed and will automatically take over the animation-duration from the linked animation. You may still see traces of it in the demos, but you can safely ignore it.

To associate our @scroll-timeline with our CSS animation, we use the new animation-timeline CSS property, and have it refer to the timeline’s name.

#progressbar {   animation: 1s linear forwards adjust-progressbar;   animation-timeline: scroll-in-document-timeline; /* 👈 THIS! */ }

With that set up the adjust-progressbar animation won’t run automatically on page load, but will only advance as we scroll down the page.

For a more in-depth introduction to @scroll-timeline please refer to Part 1 and Part 2 of my series on the future of scroll-linked animations.

The first post looks at each descriptor/property in more detail, explaining them with an example to go along with them, before covering many more interesting demos.

The second post digs even deeper, looking into Element-Based Offsets, which allow us to drive an animation as an element appears into and disappears from the scrollport as we scroll.

An example of what you can achieve with CSS Scroll-Linked Animations using Element-Based Offsets.

Practical use cases

Apart from the progress par demo above, there are a few more use cases or scenarios where scroll-linked animations can replace a solution typically implemented using JavaScript.

  1. parallax header
  2. image reveal/hide
  3. typing animation
  4. carousel indicators
  5. scrollspy

Parallax header

A typical use case for Scroll-Linked Animations is a parallax effect, where several sections of a page seem to have a different scrolling speed. There’s a way to create these type of effects using only CSS, but that requires mind-bending transform hacks involving translate-z() and scale().

Inspired upon the Firewatch Header—which uses the mentioned transform hack—I created this version that uses a CSS scroll timeline:

Compared to the original demo:

  • The markup was kept, except for that extra .parallax__cover that’s no longer needed.
  • The <body> was given a min-height to create some scroll-estate.
  • The positioning of the .parallax element and its .parallax_layer child elements was tweaked.
  • The transform/perspective-hack was replaced with a scroll timeline.

Each different layer uses the same scroll timeline: scroll over a distance of 100vh.

@scroll-timeline scroll-for-100vh {   time-range: 1s;   scroll-offsets: 0, 100vh; }  .parallax__layer {   animation: 1s parallax linear;   animation-timeline: scroll-for-100vh; }

What’s different between layers is the distance that they move as we scroll down:

  • The foremost layer should stay in place, eg. move for 0vh.
  • The last layer should should move the fastest, e.g. 100vh.
  • All layers in between are interpolated.
@keyframes parallax {   to {     transform: translateY(var(--offset));   } }  .parallax__layer__0 {   --offset: 100vh; }  .parallax__layer__1 {   --offset: 83vh; }  .parallax__layer__2 {   --offset: 67vh; }  .parallax__layer__3 {   --offset: 50vh; }  .parallax__layer__4 {   --offset: 34vh; }  .parallax__layer__5 {   --offset: 17vh; }  .parallax__layer__6 {   --offset: 0vh; }

As the foremost layers move over a greater distance, they appear to move faster than the lower layers, achieving the parallax effect.

Image reveal/hide

Another great use-case for scroll linked animations is an image reveal: an image slides into view as it appears.

By default, the image is given an opacity of 0 and is masked using a clip-path:

#revealing-image {   opacity: 0;   clip-path: inset(45% 20% 45% 20%); }

In the end-state we want the image to be fully visible, so we sent the end-frame of our animation to reflect that:

@keyframes reveal {   to {     clip-path: inset(0% 0% 0% 0%);     opacity: 1;   } }

By using element-based offsets as our scroll timeline offsets, we can have it so thar the image begins to appear only when the image itself slides into view.

@scroll-timeline revealing-image-timeline {   scroll-offsets:     selector(#revealing-image) end 0.5,     selector(#revealing-image) end 1   ; }  #revealing-image {   animation: reveal 1s linear forwards;   animation-timeline: revealing-image-timeline; }

😵 Can’t follow with those element-based offsets? This visualization/tool has got you covered.

Typing animation

As CSS scroll timelines can be linked to any existing CSS animation, you can basically take any CSS Animation demo and transform it. Take this typing animation for example:

With the addition of a scroll timeline and the animation-timeline property, it can be adjusted to “type on scroll”:

Note that to create some scroll-estate the <body>was also given a height of 300vh.

Using a different animation, the code above can easily be adjusted to create a zoom on scroll effect:

I can see these two working great for article intros.

One of the components of a carousel (aka slider) is an indicator that exposes how many slides it contains, as well as which slide is currently active. This is typically done using bullets.

This again is something we will be able to achieve using a CSS scroll timeline, as shown in this demo created by Fabrizio Calderan:

The active state bullet is injected via .slider nav::before and has an animation set that moves it over the other bullets

/* Styling of the dots */ .slider nav::before, .slider a {   inline-size: 1rem;   aspect-ratio: 1;   border-radius: 50%;   background: #9bc; }  /* Positioning of the active dot */ .slider nav::before {   content: "";   position: absolute;   z-index: 1;   display: block;   cursor: not-allowed;   transform: translateX(0);   animation: dot 1s steps(1, end) 0s forwards; }  /* Position over time of the active dot */ @keyframes dot {   0%      { transform: translateX(0); }   33%      { transform: translateX(calc((100% + var(--gap)) * 1)); }   66%      { transform: translateX(calc((100% + var(--gap)) * 2)); }    100%      { transform: translateX(calc((100% + var(--gap)) * 3)); } }

By attaching a @scroll-timeline onto the slider, the dot that indicates the active state can move as you scroll:

@scroll-timeline slide {   source: selector(#s);   orientation: inline;  }  .slider nav::before {   /* etc. */   animation-timeline: slide; }

The dot only moves after the slide has snapped to its position thanks to the inclusion of a steps() function in the animation. When removing it, it becomes more clear how the dot moves as you scroll

💡 This feels like the final missing piece to Christian Shaefer’s CSS-only carousel.


Back in early 2020, I created a sticky table of contents with scrolling active states. The final part to creating the demo was to use IntersectionObserver to set the active states in the table of contents (ToC) as you scroll up/down the document.

Unlike the carousel indicators demo from above we can’t simply get there by moving a single dot around, as it’s the texts in the ToC that get adjusted. To approach this situation, we need to attach two animations onto each element in the ToC:

  1. The first animation is to visually activate the ToC item when the proper section comes into view at the bottom edge of the document.
  2. The second animation is to visually deactivate the ToC item when the proper section slides out of view at the top edge of the document.
.section-nav li > a {   animation:     1s activate-on-enter linear forwards,     1s deactivate-on-leave linear forwards; }

As we have two animations, we also need to create two scroll timelines, and this for each section of the content. Take the #introduction section for example:

@scroll-timeline section-introduction-enter {   source: auto;   scroll-offsets:     selector(#introduction) end 0,     selector(#introduction) end 1; }  @scroll-timeline section-introduction-leave {   source: auto;   scroll-offsets:     selector(#introduction) start 1,     selector(#introduction) start 0; }

Once both of these timelines are linked to both animations, everything will work as expected:

.section-nav li > a[href"#introduction"] {   animation-timeline:     section-introduction-enter,     section-introduction-leave; }

In closing

I hope I have convinced you of the potential offered by the CSS Scroll-linked Animations specification. Unfortunately, it’s only supported in Chromium-based browsers right now, hidden behind a flag.

Given this potential, I personally hope that—once the specification settles onto a certain syntax—other browser vendors will follow suit. If you too would like to see Scroll-Linked Animations land in other browsers, you can actively star/follow the relevant browser issues.

By actively starring issues, us developers can signal our interest into these features to browser vendors.

The post Practical Use Cases for Scroll-Linked Animations in CSS with Scroll Timelines appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Practical Use Cases for JavaScript’s closest() Method

Have you ever had the problem of finding the parent of a DOM node in JavaScript, but aren’t sure how many levels you have to traverse up to get to it? Let’s look at this HTML for instance:

<div data-id="123">   <button>Click me</button> </div>

That’s pretty straightforward, right? Say you want to get the value of data-id after a user clicks the button:

var button = document.querySelector("button"); 
 button.addEventListener("click", (evt) => {   console.log(evt.target.parentNode.dataset.id);   // prints "123" });

In this very case, the Node.parentNode API is sufficient. What it does is return the parent node of a given element. In the above example, evt.targetis the button clicked; its parent node is the div with the data attribute.

But what if the HTML structure is nested deeper than that? It could even be dynamic, depending on its content.

<div data-id="123">   <article>     <header>       <h1>Some title</h1>       <button>Click me</button>     </header>      <!-- ... -->   </article> </div>

Our job just got considerably more difficult by adding a few more HTML elements. Sure, we could do something like element.parentNode.parentNode.parentNode.dataset.id, but come on… that isn’t elegant, reusable or scalable.

The old way: Using a while-loop

One solution would be to make use of a while loop that runs until the parent node has been found.

function getParentNode(el, tagName) {   while (el && el.parentNode) {     el = el.parentNode;          if (el && el.tagName == tagName.toUpperCase()) {       return el;     }   }      return null; }

Using the same HTML example from above again, it would look like this:

var button = document.querySelector("button"); 
 console.log(getParentNode(button, 'div').dataset.id); // prints "123"

This solution is far from perfect. Imagine if you want to use IDs or classes or any other type of selector, instead of the tag name. At least it allows for a variable number of child nodes between the parent and our source.

There’s also jQuery

Back in the day, if you didn’t wanted to deal with writing the sort of function we did above for each application (and let’s be real, who wants that?), then a library like jQuery came in handy (and it still does). It offers a .closest() method for exactly that:

$  ("button").closest("[data-id='123']")

The new way: Using Element.closest()

Even though jQuery is still a valid approach (hey, some of us are beholden to it), adding it to a project only for this one method is overkill, especially if you can have the same with native JavaScript.

And that’s where Element.closest comes into action:

var button = document.querySelector("button"); 
 console.log(button.closest("div")); // prints the HTMLDivElement

There we go! That’s how easy it can be, and without any libraries or extra code.

Element.closest() allows us to traverse up the DOM until we get an element that matches the given selector. The awesomeness is that we can pass any selector we would also give to Element.querySelector or Element.querySelectorAll. It can be an ID, class, data attribute, tag, or whatever.

element.closest("#my-id"); // yep element.closest(".some-class"); // yep element.closest("[data-id]:not(article)") // hell yeah

If Element.closest finds the parent node based on the given selector, it returns it the same way as  document.querySelector. Otherwise, if it doesn’t find a parent, it returns null instead, making it easy to use with if conditions:

var button = document.querySelector("button"); 
 console.log(button.closest(".i-am-in-the-dom")); // prints HTMLElement 
 console.log(button.closest(".i-am-not-here")); // prints null 
 if (button.closest(".i-am-in-the-dom")) {   console.log("Hello there!"); } else {   console.log(":("); }

Ready for a few real-life examples? Let’s go!

Use Case 1: Dropdowns

Our first demo is a basic (and far from perfect) implementation of a dropdown menu that opens after clicking one of the top-level menu items. Notice how the menu stays open even when clicking anywhere inside the dropdown or selecting text? But click somewhere on the outside, and it closes.

The Element.closest API is what detects that outside click. The dropdown itself is a <ul> element with a .menu-dropdown class, so clicking anywhere outside the menu will close it. That’s because the value for evt.target.closest(".menu-dropdown") is going to be null since there is no parent node with this class.

function handleClick(evt) {   // ...      // if a click happens somewhere outside the dropdown, close it.   if (!evt.target.closest(".menu-dropdown")) {     menu.classList.add("is-hidden");     navigation.classList.remove("is-expanded");   } }

Inside the handleClick callback function, a condition decides what to do: close the dropdown. If somewhere else inside the unordered list is clicked, Element.closest will find and return it, causing the dropdown to stay open.

Use Case 2: Tables

This second example renders a table that displays user information, let’s say as a component in a dashboard. Each user has an ID, but instead of showing it, we save it as a data attribute for each <tr> element.

<table>   <!-- ... -->   <tr data-userid="1">     <td>       <input type="checkbox" data-action="select">     </td>     <td>John Doe</td>     <td>john.doe@gmail.com</td>     <td>       <button type="button" data-action="edit">Edit</button>       <button type="button" data-action="delete">Delete</button>     </td>   </tr> </table>

The last column contains two buttons for editing and deleting a user from the table. The first button has a data-action attribute of edit, and the second button is delete. When we click on either of them, we want to trigger some action (like sending a request to a server), but for that, the user ID is needed.

A click event listener is attached to the global window object, so whenever the user clicks somewhere on the page, the callback function handleClick is called.

function handleClick(evt) {   var { action } = evt.target.dataset;      if (action) {     // `action` only exists on buttons and checkboxes in the table.     let userId = getUserId(evt.target);          if (action == "edit") {       alert(`Edit user with ID of $  {userId}`);     } else if (action == "delete") {       alert(`Delete user with ID of $  {userId}`);     } else if (action == "select") {       alert(`Selected user with ID of $  {userId}`);     }   } }

If a click happens somewhere else other than one of these buttons, no data-action attribute exists, hence nothing happens. However, when clicking on either button, the action will be determined (that’s called event delegation by the way), and as the next step, the user ID will be retrieved by calling getUserId:

function getUserId(target) {   // `target` is always a button or checkbox.   return target.closest("[data-userid]").dataset.userid; }

This function expects a DOM node as the only parameter and, when called, uses Element.closest to find the table row that contains the pressed button. It then returns the data-userid value, which can now be used to send a request to a server.

Use Case 3: Tables in React

Let’s stick with the table example and see how we’d handle it on a React project. Here’s the code for a component that returns a table:

function TableView({ users }) {   function handleClick(evt) {     var userId = evt.currentTarget     .closest("[data-userid]")     .getAttribute("data-userid"); 
     // do something with `userId`   } 
   return (     <table>       {users.map((user) => (         <tr key={user.id} data-userid={user.id}>           <td>{user.name}</td>           <td>{user.email}</td>           <td>             <button onClick={handleClick}>Edit</button>           </td>         </tr>       ))}     </table>   ); }

I find that this use case comes up frequently — it’s fairly common to map over a set of data and display it in a list or table, then allow the user to do something with it. Many people use inline arrow-functions, like so:

<button onClick={() => handleClick(user.id)}>Edit</button>

While this is also a valid way of solving the issue, I prefer to use the data-userid technique. One of the drawbacks of the inline arrow-function is that each time React re-renders the list, it needs to create the callback function again, resulting in a possible performance issue when dealing with large amounts of data.

In the callback function, we simply deal with the event by extracting the target (the button) and getting the parent <tr> element that contains the data-userid value.

function handleClick(evt) {   var userId = evt.target   .closest("[data-userid]")   .getAttribute("data-userid"); 
   // do something with `userId` }

Use Case 4: Modals

This last example is another component I’m sure you’ve all encountered at some point: a modal. Modals are often challenging to implement since they need to provide a lot of features while being accessible and (ideally) good looking.

We want to focus on how to close the modal. In this example, that’s possible by either pressing Esc on a keyboard, clicking on a button in the modal, or clicking anywhere outside the modal.

In our JavaScript, we want to listen for clicks somewhere in the modal:

var modal = document.querySelector(".modal-outer");  modal.addEventListener("click", handleModalClick);

The modal is hidden by default through a .is-hidden utility class. It’s only when a user clicks the big red button that the modal opens by removing this class. And once the modal is open, clicking anywhere inside it — with the exception of the close button — will not inadvertently close it. The event listener callback function is responsible for that:

function handleModalClick(evt) {   // `evt.target` is the DOM node the user clicked on.   if (!evt.target.closest(".modal-inner")) {     handleModalClose();   } }

evt.target is the DOM node that’s clicked which, in this example, is the entire backdrop behind the modal, <div class="modal-outer">. This DOM node is not within <div class="modal-inner">, hence Element.closest() can bubble up all it wants and won’t find it. The condition checks for that and triggers the handleModalClose function.

Clicking somewhere inside the nodal, say the heading, would make <div class="modal-inner"> the parent node. In that case, the condition isn’t truthy, leaving the modal in its open state.

Oh, and about browser support…

As with any cool “new” JavaScript API, browser support is something to consider. The good news is that Element.closest is not that new and is supported in all of the major browsers for quite some time, with a whopping 94% support coverage. I’d say this qualifies as safe to use in a production environment.

The only browser not offering any support whatsoever is Internet Explorer (all versions). If you have to support IE, then you might be better off with the jQuery approach.

As you can see, there are some pretty solid use cases for Element.closest. What libraries, like jQuery, made relatively easy for us in the past can now be used natively with vanilla JavaScript.

Thanks to the good browser support and easy-to-use API, I heavily depend on this little method in many applications and haven’t been disappointed, yet.

Do you have any other interesting use cases? Feel free to let me know.

The post Practical Use Cases for JavaScript’s closest() Method appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , ,