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

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

@matatk Thanks for sharing the APA group's thoughts; it's really reassuring that I'm not alone in having concerns.

Since you'll be meeting to discuss this tomorrow, I'd like to try one more time to make sense of this proposal and where I would prefer to see things go. Obviously I'm not the person who has to be accountable for getting things specced or shipped, but I really have spent a great deal of time over the last decade or so thinking about these issues.

I think that the shape of the proposal here, when presented as a solution to the problems of carousels specifically, represents a fairly severe scope creep. There was a solution proposed in https://github.com/w3c/csswg-drafts/issues/10711 which is not mentioned as a considered alternative in the explainer linked in this issue, but which I think fits nicely on to the problem as described:

> 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](https://www.w3.org/TR/css-scroll-snap-1/#optimal-viewing-region) of the scrolling container inert as it would be if it were `display: none`.

In particular, I noticed [in the BBC carousel guidance](https://bbc.github.io/gel/components/carousels/#inert-items):

> As the user scrolls by mouse, touch, gesture, or by using the auxiliary buttons, browsers that support `IntersectionObserver` add the `inert` attribute to items that go out of view and remove it from items that come into view.

Much of the early discussion on https://github.com/w3c/csswg-drafts/issues/10711 favoured this proposal, and even notes that it doesn't rule out a more general `inert` property in CSS.

However, in the course of the discussion, several adjacent problems were drawn in:
1. On-screen content which also needs to be inert (and, presumably, needs to be made so without using JavaScript to set the `inert` attribute).
   -  This is vaguely mentioned in the [22 August IRC log](https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2302563007) but without a specific use case; Rob elaborated in a later [reply to my comment in the issue](https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2378366874) that the specific use case was "being obscured by a foreground tab". (I'm not sure whether it wasn't minuted in the earlier discussion, or whether this was from a separate discussion, but I can't find any more details on that scenario.)
2. [Content which needs to "undo" inertness.](https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2310842738)
   - Much later in the discussion, @scottaohara [elaborated](https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2379610168) on scenarios where this would be necessary.

I don't have enough information about the scenario envisaged in (1) to understand how the proposal here applies to it; at a guess, it's an implementation of a tabbed interface where tabpanel contents are stacked on top of one another so that only the front panel is visually accessible, but the rest can't be `visibility: hidden` or `display: none` for some unspecified reason.

For 2/3 of the scenarios Scott lists for (2), I don't think this proposal even actually helps directly, except inasmuch as it allows authors to give up on modal `<dialog>` by providing a (IMO) fairly bad alternative:
- Since it doesn't (and probably shouldn't) allow escaping inertness caused by a modal `<dialog>` showing, it can't help with live regions outside of the dialog being made inert;
- Likewise, it can't help with popovers showing on top of a modal `<dialog>` being erroneously made inert.

The reason I believe it's a fairly bad alternative to modal `<dialog>` is that it still requires authors to draw the rest of the owl (i.e. implement all the behaviour of `<dialog>` from scratch), and that it doesn't even have `<dialog>`'s ability to *really* make the rest of the page inert; whether something is inert or not is based purely on what rule ends up applying on that element.

Even for the "UI tour" example Scott gives, I think the same risk applies without the strong inertness provided by `<dialog>` or `inert`: you have to trust all the developers directly or indirectly working on a given page not to author styles which cause an element to become un-inert when you don't intend it to be, and unlike with the majority of CSS properties you don't even get any visual indication that your styles have inadvertently become broken.

**What would I prefer?**

I think the problem stated in the explainer is well worth solving, and I think the option mentioned above which @flackr originally proposed is a nice solution, without the problems inherent in the current proposal. 

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 [@emilio's comment](https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1843685422).

Regarding undoing inertness, I linked earlier to my [comment](https://github.com/w3c/csswg-drafts/pull/11178#discussion_r1845716939) on the PR arguing that the situations where authors want to be able to "undo" inert would probably be better addressed using a mechanism based on the top layer primitive. Mason even filed [an issue](https://github.com/whatwg/html/issues/10811) to at least address the "popover on top of a modal dialog shouldn't be inert by default" problem. In a comment on that issue, I [fleshed out](https://github.com/whatwg/html/issues/10811#issuecomment-2540247720) a little more my ideal scenario for how this should function:

> I think if I could wave a magic wand, I would make the dialog "blocking" behaviour instead a function of the top layer under certain circumstances. Then, everything above the "blocking" top layer would be excluded from the inerting behaviour, and everything below it would be included. That would remain consistent with the current behaviour of `<dialog>` and fullscreen elements, other than the undesirable behaviour described in this issue. It would also be consistent with the visual appearance of relevant top layer elements. Dialogs' blocking behaviour is visually indicated by positioning them such that they visually block other other content, often with a backdrop. Likewise for fullscreen elements, which obscure literally all other content other than higher top layers.

I think a full exploration of inert-escaping scenarios would also be highly worthwhile: the fact that developers were so eager to add it to the scope of this issue shows that there is a very real and urgent need there. However, I don't think they've been done justice here.

> just to make sure I understand from a process perspective, this means you believe the CSS WG came to the incorrect [decision](https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2379913684) in the debate they had on this back in September, right?

Sure.

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

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