Lea: I have opinions. Left a comment. The use cases are obvious, no doubts about that. Seems like a bunch of things all together and the utility has to do with positioning and overflow, and these are things that should be solved in CSS instead of adding more magic that cannot be described by the stylesheet. Already proposals in CSS WG about how to deal with it, space for more. I don't think we should solve this with a new html element, should solve in CSS and use it in UA stylesheet. Some more points about attribute names.

Tess: the html folks don't like to have magic either. I agree with Lea that positioning stuff, whichi snot spelled out, is the interesting part - missing in CSS that would be useful for tons of things. Beyond how the positioning works, it's not novel or challenging.

Lea: I think there are use cases for stuff beyond positining. Could come with basic defaults. Coule help with accessibility, tabbing order, things CSS can't address. Eg. anchor the popup to an element which could affect tabbing order.

Rossen: majority is already in dialog

Dan: so why are they proposing it? a lot of people behind it. Is it ergonomics? an easier way to do something that can be done already? Does the need for this highlight a hole in the platform that we need to be responsive about?

Lea: the platform doesn't do this, it just shouldn't be done by an html element. The behaviour of popups spilling out of a container with overflow:hidden there's no way to do that today declaratively. Ergonomics like the light dismiss behaviour, can be done already but is just a convenience. A bag of features that come with it, they're all useful, but not sure it's the right place.

Rossen: yep. Feedback I had from them was around that, compared to dialog there are problems they want solved.

Tess: I can leave a comment

Peter: the light dismiss behaviour, another review Tess and I did on [??] that should be coordinated into this. Should reuse instead of inventing something else.

[reassign at plenary]

Lea: we gave a fair bit of feedback - they added an open attribute as part of that response. They also added a popup attribute - you put it on elements you want to trigger a specific popup but no indication on [how to use it]. Also: there was a lot of talk about how this relates to CSS. But this then becomes a 2-part proposal and the other part hasn't been proposed yet. There are autofocus and delegatesfocus attributes.. scoping issues. Dismiss behavior - no way to turn it off - has been a problem for dialog authors are complaining about customization. Could mean any time they have to do something custom they just implement it themselves.

Peter: there was another proposal for a dismiss listener

Tess: I like dialog behaviour, escape is always a way to get out. Sites don't always do the right thing, we don't want a user to get stuck in a modal without any way to get back to the page. Agree sites should be able to add custom ways of exiting the thing, but important for the browser to always provide a way to get out

Lea: there are valid reasons where you might want to make a popup not closeable. Isn't that the point of a modal?

Tess: fullscreen as an example, it has to be exitable. The app might have lots of reasons for making it not, but the applications reasons are lower than the users needs.

Lea: absolutely, but fullscreen takes over your entire screen where as a modal is only within the current page

Ken: on mobile it's full screen...

Tess: backdrop overlay behind a modal prevents selecting text on the page.. A lot that a modal can stop you from doing.

Lea: light dismiss is not.. it's easier to dismiss a popup than a dialog, not just escape key, cicking outside dismisses it, this seems like something authors would want to be able to trap

Tess: I think you should be able to exit by clicking outside, should be default

Ken: yeah

Lea: default yes, but only behaviour?

Tess: additional ways to exit that's fine. I don't think it should get in the way

Ken: don't want people to block it from exiting. Stupid mistakes like a cookie banner behind that you can't exit. I want really compelling use cases where you want to block people from exiting

Tess: block until you make a choice between three things but a script inserts content so you can't pick the things, and never get out of it

Lea: okay

Peter: if the api surface guarantees that there's always a way to exit the apps have to design around that, and respect the fact it might be exited without a choice and deal with that however they deal with it, and that's a better user experience. Agree that there should be a way for the authors to be notified of the fact it was dismissed, regardless of how it was dismissed

Lea: they have a close event, like dialog

Peter: context that it was dismissed vs closed because it was interacted with?

Lea: I don't think so.

Peter: might be important to know that

Lea: it's a hide event. That should probably be harmonised with dialog and have the same event name

Ken: that would make sense

Tess: yes should align with dialog. Consistency is good.

Peter: and there was another proposal, dismiss watcher, we had issues with that and think it shouldn't proceed but if it does, they should use that, consistently across the platform

Lea: what about the popup attribute?

Tess: am worried about it because we still don't know the positioning story. How that's going to work? We shouldn't be sprouting html features that tie into an undefined positining thing. The positining thing might inform us of how it should tie into html, maybe an attribute isn't the right way, we shouldn't constrain the CSS WG before it makes progress on this.

Lea: apply to anchor attribute as well? seems more essential

Tess: Maybe. Cart before the horse. I get the temptation to do the parts that aren't hard. We need enough of an idea of how the hard parts work so we can do this part.

Lea: what do you think about tabbing? if you have a popup anchored to another element should tabbing from the anchor focus the popup?

Tess: I don't know

Ken: should be easy to focus a popup

Tess: if anchor is a button and you press the button it causes the popup I wouldn't want the popup until I activate the button not just focus

Ken: but don't want focus on something behind the popup

Tess: if the popup pops up automatically when the button gets focussed you're in a weird positon where the focused element is behind the popup. If you wanta UI with a button to cause a popup, pressing the button should cause focus to move to inside the popup. Other UIs you might ave something that isn't a button that is focusable and you want when it focuses to cause a popup to come up.. can imagine wanting that.. seems problemantic because you get a cycle where youf ocus the thing, casues thepopup, focus gets moved inside the popup which blurs the thing that causes the popup to appear which causes the popup to disappear

Lea: moving automatically to the popup is disruptive

Ken: more weird if it stays behind and is like a toggle

Lea: anchor doesn't specify how the popup is shown, that is managed separately by adding open attribute or calling show method. Anchor tells the popup what was the invoker element. If you have an invoker element and press tab, where should focus go?

Tess: focus is currently in the popup?

Lea: no, focus is on the button that triggers the popup, button is still focussed, press tab

Tess: the button blurs and there's a chance the popup goes away. If you focus inside the popup and make the popup disappear that's not great

Lea: that will happen regardless of what the next focus eleemnt is. Should the anchoring relaitonship between the popup and the invoker override any existing tab order? should it also establish a tabbing order when you make an element the anchor of a popup?

Tess: if the popup is open you should be able to tab to the things in it, somehow. Where in the order I don't know.

Lea: that's a separate issue. Sometimes authors put the popup in a separate place in the DOM so without manual management of the tabbing order tabbing would go to another element not the popup. Could the relationship mandate a tabbing order? could help accessibility but could get in the way. Enforcing a tabbing order that is relative is a pain. if authors have to do this manually

Tess: they'll get it wrong. Does seem like it should do it.

Lea: maybe it should be easier to have a relative tabbing order

Peter: if you've activated a button that should move the focus within the popup

Lea: without tabbing? They have a separate attribute for that, autofocus. Also delegates focus attribute which means if the popup gets focussed the focus moves automatically to the first descendent element that is focusable.

Ken: that exists in web components

Lea: that sounds like more useful as a global concept and not special to popup

Ken: maybe

Dan: we're trying to design a feature.. What feedback can we give?

Hadley: have we asked them about tabbing?

Lea: they are trying to decide so wondering if we can provide input

Hadley: sounds like we might be in a better position to react to what they propose? I didn't hear consensus between all of you.

Peter: we'd like to see the rest of this designed before we thumbs up and they should come back when the rest has been figured out.

Lea: yeah

Peter: someone write that. Maybe premature to define some of these attributes until we have the rest of the story.

Lea: will write. Ask them to ping us when the rest is designed.

Ken: or maybe we have given the feedback on early and they should file a more mature review?

Peter: yeah. Close but tell them when the rest is designed please open a new issue and link a reference to this one.

Dan: feels like a lot of good valuable discussion just now.