Should <dialog> actually create a "control group" for focus? #2171
Comments
|
@domenic Blink's current behaviour makes sense to me. If someone decides to put a non-modal dialog's close button outside the dialog (AFAIK nothing in the spec says the author should avoid that), it makes sense to let the user tab through it, because unlike modal dialogs it's not possible to use the escape key to dismiss the dialog. |
|
@karlgroves pointed at the ARIA design patterns advice which suggests that it should be a tab trap/control group owner, but that the F6 key should (effectively) cycle between the control groups on the page. I think that would be ideal, but if we don't implement the cycling between control groups behaviour then the specced behaviour is a tab trap for keyboard users. |
|
Oh - F6 in Chrome moves focus to the URL bar. |
|
Assigning to @TakayoshiKochi to help remove this feature. It would have been nice to make non-modal dialogs keep focus within them. (By default, with an affordance for escaping, as @alice says). But it seems nobody's interested in implementing that. Also, @alice, please speak up if you think this is something you or your team would be interested in making work in Chrome. I assume not since you all have a lot on your plate already, but if you want to make it work we can continue the discussion. /cc @rniwa @cdumez just in case there are plans to implement dialog in WebKit soon. |
|
Note that @TakayoshiKochi created #3566 so this is moving forward. If there are any remaining concerns right now would be a great time to air them. |
This change mechanically removes the concept of "dialog group", its definition, and its references. In doing so, the three focus fixup rules collapsed to one (now just named "focus fixup rule"), and the concept of "primary control group" became unnecessary. "Dialog group" was used to define the focusing behavior of nested dialogs (mainly for the non-modal case), but actual implementations don't follow that behavior. This is a step toward removing "control groups" completely, per #2171.
The control group concept existed to give special focus behavior to <dialog> elements, treating them on par with Documents in terms of allowing focus to shift inside of them. However, this was never implemented in user agents. This change removes the control group concept, instead using Document directly. This allows some simplifications, e.g. because the first focusable area of a non-empty Document is always the Document's viewport. The change uncovered some areas of the spec that were potentially wrong or unclear when considering focus around documents. We will follow up on that in #3675. But for now we keep the same algorithms, just without <dialog>s. Fixes #2171.
This change mechanically removes the concept of "dialog group", its definition, and its references. In doing so, the three focus fixup rules collapsed to one (now just named "focus fixup rule"), and the concept of "primary control group" became unnecessary. "Dialog group" was used to define the focusing behavior of nested dialogs (mainly for the non-modal case), but actual implementations don't follow that behavior. This is a step toward removing "control groups" completely, per whatwg#2171.
The control group concept existed to give special focus behavior to <dialog> elements, treating them on par with Documents in terms of allowing focus to shift inside of them. However, this was never implemented in user agents. This change removes the control group concept, instead using Document directly. This allows some simplifications, e.g. because the first focusable area of a non-empty Document is always the Document's viewport. The change uncovered some areas of the spec that were potentially wrong or unclear when considering focus around documents. We will follow up on that in whatwg#3675. But for now we keep the same algorithms, just without <dialog>s. Fixes whatwg#2171.
|
@aleventhal told me that @mcking65 is interested in revisiting this issue |
domenic
added
addition/proposal
|
I think at this point a new issue with a clear summary would help a lot to evaluate the proposal as all of the infrastructure surrounding the feature in OP has been removed. |
I think that #7707 could replace this, based on the issue description |
Right now, per spec, dialogs are "control group owner objects". The only other control group owner object is the viewport itself. Control group owner objects create control groups for the purpose of focus. This means that even for non-modal dialogs, per spec, tabbing around within a dialog is supposed to keep the focus on controls in the dialog.
Note that for modal dialogs, this is unobservable, because they make everything else on the page inert---so there's nothing to tab to anyway. This is mostly about the behavior of non-modal dialogs.
However, Blink does not implement this. Demo. Since @nt1m has started implementing
<dialog>in Gecko, the question of whether we want to keep this behavior in the spec becomes more urgent. Should the spec align with Blink, and not treat (non-modal) dialogs as special? Or should we keep it as-is? How does Gecko feel about this question?My two cents: I think the spec's control group concept is a nice feature. Non-modal dialogs in conventional desktop UIs definitely constrain the tab order to within them. But non-modal dialogs are not super-popular on the web, in my experience, so maybe making them work well is not worthwhile. And getting dialog implemented has been a long road, so we should weigh implementer willingness heavily here.
/cc @nt1m @TakayoshiKochi @alice @robdodson @danbeam @freshp86 as people I know interested in dialogs/focus
Note to self: if we decide to go with Blink's behavior, remember to close https://www.w3.org/Bugs/Public/show_bug.cgi?id=24720
The text was updated successfully, but these errors were encountered: