Remove concept of expressly inert?

[Loirooriol]

https://html.spec.whatwg.org/multipage/interaction.html#expressly-inert

An element is expressly inert if it is inert and its node document is not inert.

I was trying to understand if I implemented this right in Blink, but I don't really get the reasoning behind the concept.

The difference is that

When a node is inert, then the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of find-in-page, and may prevent the user from selecting text in that node.

while focusability typically requires not being "expressly inert" (so an inert element can be focusable if its document is inert).

There are different ways in which nodes can become inert:

• If there is a modal dialog:

  A Document document is blocked by a modal dialog subject if subject is the topmost dialog element in document's top layer. While document is so blocked, every node that is connected to document, with the exception of the subject element and its shadow-including descendants, must be marked inert.

  The DOM spec defines "connected" for elements, though it's used in nodes in general (document.isConnected === true). However, I don't think that we want to allow focusability of elements outside the modal dialog by marking the document node as inert. What I'm saying is according to implementations and what @domenic said in Should <dialog> actually create a "control group" for focus? #2171:

  modal dialogs [...] make everything else on the page inert---so there's nothing to tab to anyway.

  So either the document node is not marked as inert by modal dialogs (so all inert elements are also expressly inert), or focusability should check inertness instead of expressly inert.

• Nested browsing contexts:

  While a browsing context container is marked as inert, its nested browsing context's active document, and all nodes in that Document, must be marked as inert.

  So if I have an inert iframe, the elements inside it shouldn't be selectable, but should still be focusable? Why?
  Seems specially puzzling since the nested viewport checks for plain inertness, so it won't be focusable:

  [Examples of focusable areas]
  The viewport of a Document that has a non-null browsing context and is not inert.

• The inert attribute (not yet in the spec and not shipped by implementations)
  It can only be set to elements so it's not relevant here.

I have checked #3647 and it seems that the "expressly inert" was formerly used for control groups, e.g.

Inside an inert dialog element, all descendant elements are not expressly inert, even if they are inert.

But the "control group" concept was removed, so I think "expressly inert" should be removed too, and just check for "inert".

[domenic]

I think you are right and this concept is not good. And it is probably a remnant of control groups.

But I wish I could figure out what the concept was even supposed to do, when control groups existed... why would it be useful to have the controls inside an inert dialog element be focusable? Something about nested modal dialogs??

I think if we fix this we can also clean up "When a key event is to be routed in a top-level browsing context, the user agent must run the following steps:", whose step 5 is pretty suspicious right now.

Would you be willing to work on a pull request for this?

[Loirooriol]

PR in #7565

I think if we fix this we can also clean up "When a key event is to be routed in a top-level browsing context, the user agent must run the following steps:", whose step 5 is pretty suspicious right now.

I have left the inert check since I guess it's technically possible for a DOM anchor of a focusable area to be inert in this case:

Any other element or part of an element determined by the user agent to be a focusable area, especially to aid with accessibility or to better match platform conventions.

But I have removed the example. And I have changed steps 2 and 3, since "currently focused area of the top-level browsing context" returns a "focusable area-or-null". No need to check if it returns a dialog which is not a focusable area.