Browser vendor feedback

[robdodson]

Jotting down some feedback we've received while discussing inert with other implementors:

Mozilla

"Inert is something I think is useful but it has more of an 'implement at some point' status... once the spec has more details."

@dbolter would you be able to expand a bit on what details you think are currently missing from the spec?

Safari

Reached out but unable to get comment.

Edge

We had a lengthy discussion with Edge. My best attempt at a summary is:

• Edge wondered if inert wouldn't be better served as a CSS property, instead of an HTML attribute. It could be similar to, or maybe even a part of, visibility.

/* Keyword values */
visibility: visible;
visibility: hidden;
visibility: collapse;
visibility: inert; 

Edge wondered if this would obviate the need for something like <dialog> because visibility allows subtree children to "escape" and display even if their parent is visibility: hidden. Example:

<main style="visibility: inert"> <!-- everything in main is "inerted" -->
  ...
  <div class="modal-dialog" style="visibility: visible"> <!-- this child overrides the parent and is "un-inerted">

• Edge stated they were not opposed to us continuing to work on inert as an attribute/property, or even shipping it behind a flag for experimentation, but suggested we also more thoroughly explore and explain its interaction (if any) with CSS. Some of this work has already been done in the Wouldn't this be better as...? section.

cc @boggydigital, @travisleithead, @dbolter, @nt1m, @cookiecrook, @alice to make sure I captured everyone's positions accurately. BTW thank you all for taking the time to discuss this with us 😊

[nt1m]

Not necessarily Mozilla's opinion, but my personal opinion is close to Edge's.

I do think it is worth thinking more into whether this should be a CSS property, or something implemented in the UA sheet:

[inert] {
  pointer-events: none;
  user-select: none;
  user-focus: none; /* new property ? */
}

On the other hand, implementing inert as it is right now is somewhat consistent with the disabled attribute, so I would be fine with implementing initially as it currently is.

[Garbee]

There is a discussion on the forum on CSS Toggle States. The idea of Toggle States (if implemented in some fashion) + inert as a CSS property is super compelling. For example, it would allow a CSS-only navigation drawer to exist and be accessible. So, I feel like the Edge team has a really good idea there that deserves some further exploration.

[Malvoz]

@nt1m

Making things focusable in CSS is also discussed in WICG/spatial-navigation#25

[MelSumner]

@robdodson I'd be interested to hear an update on this, if one was available.

[robdodson]

@MelSumner I haven't personally spoken with any other browsers about focus-visible but I've been heads down working on other projects so I may be a little out of the loop. @alice do you know if there have been any conversations?

[othermaciej]

The WebKit team at Apple supports the idea of implementing inert. It's not at the very top of our priority list but we're actively considering it. We'd also support putting it back in the HTML spec

Caveat: some personal opinions I haven't discussed with the team. I don't think inert would be better expressed in CSS. CSS is about presentation, not behavior. Stuff like user-select and -webkit-user-modify seems in retrospect kind of regrettable. Also, the inability to escape inert from within a subtree seems like a feature not a bug. An inert CSS property would not be sufficient for implementing dialog either, both because of the ability to escape, and because dialog also includes novel stacking behavior.

[robdodson]

@MelSumner ah sorry, I misread and thought y'all were asking about focus-visible. I also haven't done much with inert but I know alice has been working on adding it back to the standard. whatwg/html#4288

[alice]

@othermaciej Thanks so much for the comments!

I agree with all of your personal opinions, and wanted to expand on this one:

An inert CSS property would not be sufficient for implementing dialog either, both because of the ability to escape, and because dialog also includes novel stacking behavior.

Indeed, on my backlog of "ideas to write up as concrete proposals" is a top layer API which would explain both the "inert everything else" and the stacking behaviour of dialogs. I think those two things belong together, as the "inert everything else" behaviour is visually indicated by the combination of stacking and backdrop. It would obviously reuse the definition of "inert" used by both <dialog> and the inert attribute.