Re: [w3ctag/design-reviews] CSS inert (Issue #1055)

flackr left a comment (w3ctag/design-reviews#1055)

> I have [argued](https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1845716939) that this mechanism should be instead provided only in conjunction with top-layer mechanisms.

Component-modal dialogs are a use case where putting something in the top layer is not appropriate as doing so would make it effectively globally modal preventing interaction with the rest of the page and visible even if the component wasn't visible. However, doing this correctly does require careful coordination within the components on your page - e.g. the author may have to combine with a count to determine whether the thing should really be `interactivity: auto` or not because it's inside the inert portion of an ancestor component, e.g.

```html
<my-component id=c1>
  <component-modal id=i1>
    This obscures the component and blocks interaction with the rest of the component.
  </component-modal>

  <button>This is made inert because it's covered by #i1</button>
  <my-nested-component id=c2>
    <component-modal id=i2>
      <!--
      This should still be inert since it is covered by #i1,
      css libraries would need to conditionally remove inertness based on an inherited count of inerting ancestors
      -->
    </component-modal>
    <button>This is made inert because it's covered by #i2</button>
  </my-nested-component>

</my-component>
```

Outside of uninerting, some other situations for inerting visible content (i.e. use cases that wouldn't be supported by an offscreen is inert api) are when content is technically visible, but either:
1. Not fully visible (e.g. peeking at next / previous content),
2. Obscured (e.g. tabs that animate opacity in/out or z-index forwards / backwards) or transformed such that it's not readable or intended to be interacted with e.g. via a 3d transform on previous / next items in a scrolling list. A card stacking UI is a common use case of this where the subsequent or previous elements are arranged as if below the current in a stack.
3. Low to zero opacity.

That said, the semantics of offscreen is inert is nice in that it could empower the UA to make offscreen content discoverable, see https://github.com/w3c/csswg-drafts/issues/11553

> I think that the current proposal would be less problematic at least if it worked more like the inert attribute, and didn't allow any undoing of inert by using the property (including when content is made inert by the property). This is what I had initially misunderstood was being proposed, based on https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1843685422.

This was the original proposal for the `interactivity` property, that it could not be undone and was roughly equivalent to adding the `inert` attribute, however @emilio and @nt1m https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2338876054 expressed the desire to be able to explain the underlying model we have for uninerting - as well as @scottaohara bringing up the use cases which I acknowledge you've considered in detail. I think the component-modal use case is one that wasn't discussed yet. Allowing it to be undone makes the property behave similar to `visibility` (which also applies / inertness when hidden and can undo itself) and `pointer-events` (not inert, but not also interactable with by pointing devices).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1055#issuecomment-2734217635
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1055/2734217635@github.com>