[Popup] Default focus behaviour

[erikkroes]

The explainer explains 4 ways for focus to behave.

1. autofocus on and element inside the <popup>
2. autofocus on the <popup>
3. delegatefocus on the <popup>

4. By default, focus remains on the current active element when the popup is invoked.

I understand that the first is hard to implement as a default behaviour. Of the 3 other cases, I wonder why the last one is the default. Is there a use case for this scenario? To my understanding, there are people that like both 2 and 3 for dialogs, but besides this explainer, I don't know of a preference for option 4.
I wonder which case (2, 3 of 4) is the preferred default. There is a lot of strength in a sensible default for a widely (re-)used component.

[carmacleod]

I think option 4 would be for things like comboboxes and autocompletes (search, etc) where the user can keep typing in the text field, for example.

[tlouisse]

Also, should it be possible to handle all 'focus scenarios' via markup?
W3C names a few more focus scenarios on top of the above (see the green 'Notes' section)

[melanierichards]

I think option 4 would be for things like comboboxes and autocompletes (search, etc) where the user can keep typing in the text field, for example.

Exactly, the primary use case for (4) is composited controls such as these. There's also a case to be made for "teaching UI", some little bubble that comes up on page load when you want to alert the user to some new feature (for example). Immediately pulling keyboard focus directly into that popup may be too aggressive and disruptive to the user's current task.

As for why (4) as the default, that's about trying to create the cleanest possible authoring story. To us it seemed simpler if the default were effectively "do nothing" (keep focus where it is), and then lean on prior art around autofocus and focus delegation to actually move said focus. It seemed less clean to offer a net-new mechanism to say "hey you know what browser, please unset the focus management you just did"—additive effects rather than resets. Of course, we'd be seeking feedback from authors on whether this mental model does make sense. :)

@tlouisse as far as initial focus goes, is there anything here you'd want support from the web platform on? Some of these may best handled by web app logic + setting autofocus, but I may have missed something.

[tlouisse]

Thanks @melanierichards, no focus behavior seems like the most sensible default.
Slightly related... about the "teaching ui" you mentioned: in my understanding there can be multiple of those simultaneously on the screen, like here:
https://i.pinimg.com/736x/c2/b5/a8/c2b5a835aa71ad468e8ac4ea67e9f206.jpg
Would this contradict with 'Only one “top-level” popup may be displayed at a time'?
I also pointed this out in this issue, where I called them coach marks.

Wrt the autofocus on children, that would make perfect sense indeed 👍
Few questions:

• Would it also work for shadow dom content?

<popup>
  #shadow-root
  <button autofocus></button>
</popup>

• What would happen when both host and child apply autofocus (or delegatefocus and autfocus)?

<popup autofocus>
  <button autofocus></button>
</popup>

<popup delegatefocus>
  <button></button>
  <button autofocus></button>
</popup>

• And what when content is being rendered asynchronously, right after show (since this does not work on first meaningful paint for current autofocus when rendered with a template engine like lit-html)?

[melanierichards]

Thanks all for the discussion! @tlouisse, I ported your attribute processing questions to openui/open-ui#330. Closing this issue, but if I missed anything outstanding please file a bug on Open UI! Thanks!