Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add first draft of Popup (Editor's Draft) #355

Merged
merged 18 commits into from
Aug 26, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
[Popup] Setting focus when the popup element is shown
  • Loading branch information
Melanie Richards committed Jun 5, 2021
commit 610846db9677ddef40a8693f7cd5484b9b22c1d3
61 changes: 58 additions & 3 deletions research/src/pages/popup/popup.proposal.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -216,12 +216,67 @@ attribute set to `true`, and which is not the _candidate subject_:
Step #2 probably needs to be more precise, and more specific about Shadow/light DOM
melanierichards marked this conversation as resolved.
Show resolved Hide resolved
</p>

## Setting focus when a `popup` is shown

### The `autofocus` attribute
## Setting focus when the `popup` element is shown

### The `delegatesfocus` attribute

The `delegatesfocus` attribute is a
[boolean attribute](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attribute).
When specified, it indicates that when the `popup` element is shown, focus should move to the first
melanierichards marked this conversation as resolved.
Show resolved Hide resolved
focusable descendent of the `popup` element.

**Example:**

```html
<popup delegatesfocus>
<p>I am not a focusable element.</p>
<p>Nor am I.</p>
<button>I will be focused whenever the popup becomes focused.</button>
</popup>
```

### Focusing steps

The popup [focusing steps](https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps)
for a `popup` element _subject_ are as follows:

1. If the `delegatesfocus` attribute is specified on _subject_, let _control_ be the first focusable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

defer to the delegatesfocus spec definition

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

descendant element of _subject_, in [tree order](https://dom.spec.whatwg.org/#concept-tree-order),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the spec for "Get the focusable area" should be used here, I think. And actually, I think it'd be a lot better if we folded this algorithm (focusing steps for <popup> and even <dialog>) back into the "Get the focusable area" spec. It'd be a lot cleaner, I think.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in ecb4964! I've created a new section of this document at the bottom for text that should land in the focusable area algorithm.

that is not inert and has the
[autofocus](https://html.spec.whatwg.org/multipage/interaction.html#attr-fe-autofocus) attribute
melanierichards marked this conversation as resolved.
Show resolved Hide resolved
specified.
2. If there is no such descendent, but `delegatesfocus` is specified, let _control_ be _subject_.
melanierichards marked this conversation as resolved.
Show resolved Hide resolved
3. Otherwise, if the `autofocus` attribute is specified on _subject_, let _control_ be _subject_.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I prefer for if/else type algos to have expectation in sub-bullet and be indented in. This is similar to how the code will normally look and IMO is easier to read and follow. This may not be how WHATWG does it however (having the result be another bullet).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is, unfortunately, how WHATWG typically writes if/else algorithms. Step N is "if X, do Y", and step N+1 is "otherwise, do Z".

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, I elected to follow WHATWG style here. Inviting HTML editors to weigh in on whether they'd be amenable to sub-bullets or if we should follow house style in order to land this text with minimal changes.

4. Otherwise, return.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this "returning" from?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

returning from the algorithm.

Here, I'm not sure about WHATWG conventions. This is an if/elseif/else block, as step 4 is the "otherwise" for the embedded "if" in step 3. That, I haven't exactly seen.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any changes requested, e.g. melding 4 into step 3?

5. Run the [focusing steps](https://html.spec.whatwg.org/multipage/interaction.html#focusing-steps)
for _control_.
6. Let topDocument be the
[active document](https://html.spec.whatwg.org/multipage/browsers.html#active-document) of
_control_'s [node document](https://dom.spec.whatwg.org/#concept-node-document)'s
[browsing context](https://html.spec.whatwg.org/multipage/browsers.html#concept-document-bc)'s
[top-level browsing context](https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context).
7. If control's [node document](https://dom.spec.whatwg.org/#concept-node-document)'s
[origin](https://dom.spec.whatwg.org/#concept-document-origin) is not the
[same](https://html.spec.whatwg.org/multipage/origin.html#same-origin) as the
[origin](https://dom.spec.whatwg.org/#concept-document-origin) of _topDocument_, then return.
8. [Empty](https://infra.spec.whatwg.org/#list-empty) _topDocument_'s
[autofocus candidates](https://html.spec.whatwg.org/multipage/interaction.html#autofocus-candidates).
9. Set _topDocument_'s
[autofocus processed flag](https://html.spec.whatwg.org/multipage/interaction.html#autofocus-processed-flag)
to true.

<p class="note">
Without the precense of the autofocus or delegatefocus attribute, focus remains on the active
element. This behavior is to enable scenarios where the popup is used in a composite control. For
example, a combobox where the user expects their focus to stay in the text input instead of moving
automatically to the listbox popup as and when it appears.
</p>

<p class="question">
melanierichards marked this conversation as resolved.
Show resolved Hide resolved
These focusing steps effectively assert that the delegatesfocus attribute takes precedence over
melanierichards marked this conversation as resolved.
Show resolved Hide resolved
the autofocus attribute. Is that the desired behavior?
</p>

## Anchoring a `popup` to another element

## Hiding a `popup` element
Expand Down