[Popover] Should a popover have the ability to be opened by default?

[brechtDR]

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.

[scottaohara]

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.

[brechtDR]

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
Combined with a lot of new CSS features, If we were to allow triggers on a dialog element (which is another issue already) and do the same for popover, we could potentially reduce the JS of this example to only handling the form submit.

https://codepen.io/utilitybend/pen/OJayqLY

[gregwhitworth]

@brechtDR please review #631 since it has the historical context and let me know if you want to re-visit the discussion after reviewing the threads on WHATWG and the minutes in 631.

[scottaohara]

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.

[brechtDR]

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
Also the naming was hard especially in combination with dialogs and details elements, but those had several other related topics already.

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 is talk about the ability to trigger a dialog without JS in the following issue: Have some way of opening <dialog> elements without JavaScript whatwg/html#3567
• As a side note: a dialog can get an open attribute by default to show it right away.

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.

[mrksbnch]

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 <form> in a popover.

You can use popovertarget (or JavaScript) to open the popover and use something like history.pushState to change the URL to e.g. "/users/edit/:id" (where ":id" is an ID that uniquely identifies a user). When going directly to one of these URLs, e.g. "/users/edit/:id", you want to open the popover by default. Currently, the only way to achieve this is to use JavaScript which feels counterintuitive for a native HTML element, especially if the rest of the page works just fine without JavaScript.

[github-actions]

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.

[kizu]

One thing to think about: recently there were discussions about allowing to control the open state of the <details> through CSS: w3c/csswg-drafts#9879 with the following resolutions from CSSWG:

RESOLVED: Expose the <details> contents slot as either a pseudo or a ::part, as decided in a joint meeting with WHATWG
RESOLVED: We desire to have no restrictions on the stylability of the display of <details> and <summary>

I imagine, it might be worth considering the same for popovers.

[lukewarlow]

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.