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

Popover but without the close on blur #12

Open
vincentfretin opened this issue Aug 16, 2022 · 6 comments
Open

Popover but without the close on blur #12

vincentfretin opened this issue Aug 16, 2022 · 6 comments

Comments

@vincentfretin
Copy link
Contributor

I'm using the Popover components to open a chat panel that includes latest messages and an input to enter a new message. When the popover is open, the input is focused, that's great. But I don't want the panel to close when I click outside the chat panel or inside the panel if I want to select and copy a message for example. I want the panel to stay open unless Esc or click again on the PopoverButton.
The close on blur behavior seems to be triggered by
https://github.com/lxsmnsyc/solid-headless/blob/983581b93fc06169325703c8b0aa734ff349924a/packages/solid-headless/src/components/popover/PopoverPanel.ts#L68-L70
Could we have a prop to not register this close on blur behavior? Something like <PopoverPanel closeOnFocusOut={false}> ? What do you think?

@lxsmnsyc
Copy link
Owner

Hmmm, the thing is, by specification design this is meant to be desirable behavior, however it's not entirely clear how one should approach this. Sure, we could use an overlay but Popovers don't really make the outer elements to be inert in contrast with Dialog.

My stance here is that I cannot change this by design, but I can recommend using alternatives. Frankly, if your component is a chat popup, I don't really recommend popovers.

@vincentfretin
Copy link
Contributor Author

I didn't find the Popover pattern in https://www.w3.org/WAI/ARIA/apg/
Do you have a link that describe the pattern? It looks a little bit like the Tooltip pattern.

I use the Popover component for this action, it's perfect:
Capture d’écran de 2022-08-17 09-51-42

I'm new to the accessibility patterns so I don't have much experience with them. Do you have a pattern in mind for my use case.
Here is some screenshots of my interface for a users list and chat panels:
Capture d’écran de 2022-08-17 09-44-16
Capture d’écran de 2022-08-17 09-44-03

With what I read my use case may be more like a non-modal dialog, so I should use a role="alertdialog". I tried to use AlertDialog component without AlertDialogOverlay, but I didn't succeed to use the AlertDialog with a DisclosureButton.

I found this discussion sumup-oss/circuit-ui#1354 about a SidePanel component interesting.
It seems what I'm searching for is this behavior https://www.lightningdesignsystem.com/components/panels/

@lxsmnsyc
Copy link
Owner

lxsmnsyc commented Aug 17, 2022

Here's an example implementation: https://www.w3.org/WAI/ARIA/apg/example-index/dialog-modal/datepicker-dialog.html

Popovers are actually under Dialog specification with a minor difference that is, unlike Dialogs, Popovers do not prevent the users from interacting outside the container. Popovers are closer to tooltips than to floating containers, which aren't actually dialogs. The purpose of dialogs is to lock the focus of the user inside the containers.

Panels are actually under dialogs, however I do think that accessibility-wise, panels doesn't fit your use case.

@vincentfretin
Copy link
Contributor Author

The main action in my app is to move an avatar in a 3d environment. It would need footstep sounds and sound on wall collision to be accessible but that's another story. The chat panel is a secondary action.
To me it seems Popover has everything I want aria-expanded, aria-controls, focus. The chat panel can close if I click outside of it and continue moving my avatar, I can be fine with that. For a screen reader, the user will need to close the chat panel anyway to be able to continue moving the avatar from what I understand. It's just that it currently closes when you click somewhere inside the popover that is not a focusable element, so here when the input lose focus, that's the main issue I have. The datepicker example doesn't have this behavior, you can focus a button and click inside the popover to unfocus the selected button, it doesn't close.

@vincentfretin
Copy link
Contributor Author

You can reproduce the issue in the popover example https://codesandbox.io/s/github/LXSMNSYC/solid-headless/tree/main/examples/popover-example
If you click on the thin border/padding of the popover it closes. I think it shouldn't close.

@lxsmnsyc
Copy link
Owner

Yeah that's probably an issue, I'll take a look

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants