Problem

Tab and carousel UI patterns that can be mostly created with pure HTML and CSS. #9745 is aiming to expand upon how rich of an experience can be declaratively built. The primary use cases explored here are scrolling paginated tabs or carousels. E.g.

• Tabs supporting swiping implemented by a horizontal snapping scrolling element, examples:
  • https://gui-challenges.web.app/tabs/dist/
• Carousels implemented by a horizontal snapping scrolling elements, examples:
  • https://github.com/kevin-powell/netflix-carousel-css-only
  • https://gui-challenges.web.app/carousel/dist/

The ARIA Authoring Practices Guide recommends that only the currently visible content is in the focus order, and has examples which achieve this either by:

1. using display: none (example 1, 2) when they can (i.e. when the switch between slides is immediate), or
2. by setting aria-hidden from script (example 3).

In many cases, display: none can't be used, e.g. in most of the above cases because the previous and next slide may be visible simultaneously. However, since the alternative is an HTML attribute, it requires developers to write script that listens to the appropriate events and set these states, which can be a tricky to correctly detect and is unfortunate to need for cases where the interaction is otherwise declarative (e.g. scrolling or anchor links).

Proposal

I believe there are a few ways we could approach this problem:

1. Adding a CSS inertness property, e.g. interactivity: auto | inert which was previously deferred in [css-ui] Should inertness be exposed as CSS property? #7021 awaiting better use cases. This has the potential to help with animation related cases, e.g. [css-display] Interaction gotchas when delaying the effect of display: none #8389 where we currently try to infer this temporarily visible but inert state from the underlying style. With this property, developers would still need to have a way to trigger this style change as a result of whether something is currently visible which could be based on a view-timeline, e.g.

   @keyframes interactive-when-visible {
     0% { interactivity: auto; }
     100% { interactivity: auto; }
   }
   .page {
     interactivity: inert;
     animation: interactive-when-visible;
     animation-timeline: view();
   }

   Or by a ::snapped query as in [css-scroll-snap] Proposing :snapped: exposing private snapped item browser state for developers and designers #6985:

   .page {
     interactivity: inert;
     &::snapped {
       interactivity: auto;
     }
   }

2. Adding a CSS property specifically for making offscreen content inert, e.g. overflow-interactivity: auto | inert. This would make content that does not intersect the optimal viewing region of the scrolling container inert as it would be if it were display: none.
3. Adding an enumeration value to the inert attribute similar to hidden=until-found, e.g. inert=offscreen which could behave either like option 1 or 2 depending on which made more sense.