-
Notifications
You must be signed in to change notification settings - Fork 185
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] Should a popover have the ability to be opened by default? #771
Comments
this was discussed before, but from what I recall mostly in the scope of how this wouldn't make much sense for auto popovers, since - at the time it was discussed, those still had the behavior of auto-dismissing and would have had a high probability of hiding for anyone using a keyboard attempting to navigate the web page. with that said, i suppose it's worth re-discussing since that behavior has changed, though i'm still a bit wary about the idea of popovers being open by default - particularly non-manual ones. I'm also a bit unsure about the actual use case of needing this for a toast notification - being that I'd expect a toast notification to generally be triggered by a user action, and thus would already be reliant on JavaScript to display the appropriate message. Even for a use case like a cookie-banner (likely a non-modal dialog, as should arguably be a toast notification message) where one might want that to appear by default on page load - that too seems like something that would generally be reliant on JS to display or not. But, please don't let my skepticism be mistaken for being against the idea. I'm just looking for use cases that would justify the need for this, when at least the majority of the ones I can think up (and it's still early here so i might need more coffee) with would require JS (or likely not even be a popover - that is still an option too. not everything has to be a popover :)) to accomplish anyway. |
Thank you for commenting. I totally agree that this probably isn't the most needed thing as it could be achieved with JS. But it's a typical example of "you don't need it, until you do". One other thing that comes to mind (as you noted as well) are GDPR cookie banners, I always wondered if these should have a dialog role for example or could be something different, so thank you for clarifying that. (In current implementations, they're mostly dialogs or not accessible at all to be honest). Or how about those "tour" popovers, used to highlight features on platforms where you want the initial one to open right away. The biggest benefit of having this is that you could easily re-trigger those popovers from a button if the user decides to close them right away. Without having to create a mixture between html triggers and JS triggers. That sounds pretty powerful. But agreed, they mostly have some JS written behind them to set the cookies for example. Also agree that a default open state is mostly useful for manual popovers as auto popovers would just close right away after another interaction on the screen has been made. Another benefit is that you can do this with dialogs by adding "open". So why not on popover? I can understand people asking that question in the future. Developers love consistency. But of course it shouldn't be implemented just for that sake. All this aside, when it comes to implementation, it could be as straight forward as adding "popover-open" as an attribute. Small update on the potential |
that's not a good candidate for a 'toast'. it likely should be a non-modal dialog if not a fully modal dialog due to the fact it'd be difficult for someone to know how to get to it, consistently, otherwise. and the fact that one can't dismiss it without having to move focus to it would mean it'd be a prime candidate to fail wcag 2.2's focus obscured (minimum) criterion. |
Agreed on my example not being the best use case here. I might get back on that. But first I wanted to share why I think it could be reopened after reading up on the issue mentioned by @gregwhitworth Some of the things that complicated the whole thing was animating from/to display none this has been tackled by the csswg There is a mention about consistency with the dialog element using JS, this is where I believe things are becoming hard to understand as in, "dialog can do this, popovers can't" (or the other way around) Working on consistency is happening already:
There are differences between a dialog and a popover, but we're already laying the accessibility part in the hands of developers for a lot of use cases. So why shouldn't a popover have the ability to be open by default just as with a dialog? This could be for showing a hint at pageload with light dismiss, and could - potentially - be handled with an aria-live attribute. (? question ?) Is it the biggest use case out there? Probably not. But it could remove some confusion and learning curve if a dialog as well as a popover could have a default open state. I'd love to hear some other opinions on this, but wanted to make sure we didn't just dismiss it completely without some after thought. |
There are use-cases where popovers should automatically open if you open a particular URL. Imagine that you are building an interface that shows a list of all users when you visit "/users". To edit one of these users, e.g. their first or last name, you want to show the You can use |
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label. |
One thing to think about: recently there were discussions about allowing to control the open state of the
I imagine, it might be worth considering the same for popovers. |
I have concerns with allowing you to "open" a popover with CSS. You can already force it to display block but that doesn't toggle the aria expanded state for example. That being said I do think we should allow default open popovers. |
Being able to open a popover with CSS might also mean that you could make an element a popover with CSS. If you could do that then you could make a |
So from some of the use cases that I'm seeing (which also seem to coincide with some of mine), I'm wondering if what's really coming out is a desire to have something that lets developers: 1) Make the rest of the page In my view, those are some of the strongest features of the I agree that the toast scenario doesn't quite seem to work here. But @mrksbnch's use case is actually something along the lines of what I was thinking of. The UX could technically be achieved without a An added ability to arbitrarily put something in the Top Layer could be great, but it's also probably sufficient to carefully write out the HTML and CSS so that the If the team is open to considering something that's like the
|
For the moment, I think there isn't a way to show a popover by default (on page load) in Chrome Canary
This could be handy for example to show a toast on page load which could be closed afterwards.
I mimic this behaviour by adding some JS in the following demo. But could be handy if I could just add "popover-open" as an attribute.
(scroll the page for to see the toast pop up, I'm combining this with scroll-driven-animation, which would be a cool thing to do)
https://codepen.io/utilitybend/pen/vYQLZEz
I can't seem to recall if this was discussed before.
The text was updated successfully, but these errors were encountered: