Rossen: third attempt at a TAG review..

Dan: [bump to plenary]

Rossen: explainer is nice and exhaustive

Dan: what do they mean by having a [2] but nothing that it's referencing.. in s&p..

Dan: they provided answers..

Lea: what changed from the previous attempt?

Rossen: our last one was not exhaustive right?

Dan: no signals from firefox or safari adds multi-stakeholder label

Max: [from request] "This is a third attempt at a TAG review for this feature. The first attempt was closed due to the lack of an Anchor Positioning proposal. That has now been proposed, and there's a draft spec. The second attempt was closed because we changed directions from a <popup> element to a popup content attribute. This third TAG review is for that new content-attribute-based approach."

Lea: adds on div or a?

Peter: they have examples of custom elements

Rossen: it's on element

Peter concerns me - how this interacts with other mechanisms to do the same thing. dismiss behaviour.. a close watcher type of thing.. Tess had issues.. listening to escape. one of their examples is building a date picker and that sounds like something that should be the form element and there's already an API for form elements to do popups so be nice if these things were aligned. if I'm buildng a custom element that acts as a form element maybe I should be abel to activate the popup the same way as a native form element

lea: i have a lot of rservations about extending the element api surface to that extend> I understand it's imporatnt but it adds several attributes on every single element. I'm not sure this is needed compared to having a dedicated element for htis sort of thing, which was the prvious proposal. What do others thing? Okay to add that much stuff on every element?

Peter: I think that's a valid concern. I think it's fair to be able to add this capability to custom elements, but it could be restricted to popup or custom, or have some way for the custom element inheriting from popup

Lea: or the custom element could contain a popup element in the sahdow DOM, whcih is how they inherit capabilities in other areas. We don't add to every element to become a details and summary or dialog..

Peter: their original proposal was for dedicated element

Lea: I think the pushback was that it wasn't clear what this did? I think the problem was it was an abstract class that you needed to extend to do anyting useful with

Rossen: more like an interface. Which is why, reading their explainer now, why they went odwn the path of distributing the actual abstract capabilities to the base element. Which is now taking it perhaps a step too far. I can see how that could be .. we can probably make a case fo rnumber of elements and the opposite for.. I don't see any discussion or .. reading through their goals I don't see the behaviour being intended to be so broad. I don't know what ...

Lea: regardless of the reservations for the previous proposal, compared to this I think the previous proposal was better

Rossen: in some ways yes. I like the ease of extensibility of this one. But if they were to scope thi, and it's going to be up to them to come up with use cases and data to back up which elements they would extend it to, I can see how they can make a case to the usual suspects of elements, inputs and a div perhaps, and custom elements, and keep it there. I'm nto sure what that behaviour would do for body. But then again you might come up with a use case where that is a useful thing on body.

Lea: The API shoudl be designed to accommodate the common cases

Rossen: agreed

Lea: we are concerend that they are extending every element, doesn't look like this needs to be a global behaviour. yes it's a way to address our previous feedback it would probably be better to have a popup that does somethign by default. Any other points?

Dan: I left a note asking about stakeholders/implementers

Rossen: Re-reading the goals.. the very first, "any element and arbitrary descendents" .. that by itself suggests that the popup behaviour they're describing here is intentially applicable to any element. I do'nt know what that means for table column for example..

Lea: doesn't that make it harder to implement? To deal with these complications?

Peter: something like a ?? where youw ant to take random content and surface it, but a backdrop around everything else. Back to the discussion about custom elements - they did add a mechanism for a declarative popup trigger. That mechanism does make sense to apply to custom elements in addition to popup. Even if the custom element contains a popup in its shadow DOM it makes sense for the custom element to be acting like a popup. Agree that applying this to everything is scary.

Lea: any attributes on the trigger are fine as globa. Doesn't make sense for the popup to be a set of global attributes and methods.

Peter: the thing you can trigger you want to be able to trigger custom elements in addition to popups. MySpecialPopup and trigger it with this mechanism.

Lea: extending builtins is a whole separate issue.. we're not going to fix it with popup. There are several proposals to fix this. Existing functionality for extending builtins that safari has blocked. We should nto be solving this as a one off for this use case.

Dan: focus on the scope question. Additional thing about form controls that you said Peter?

Peter: one of their examples is a datetime picker. Other form controls do popups. There's a separate proposal for how to trigger thos eprogramatically. If I build a custom element as a date picker that is a form element it would be nice if I can trigger its popup behaviour the same way as aother form elements rather than having two different APIs.

punt to plenary

see discussion below

Rossen: we did have a chance to talk about this during TPAC... we did talk about the evolution of the Popup API.. started as an API.. they made it into an element... they took it and went down attribute path... we raised a flag about this... tl;dr their position - they want to rescope the attribute to which elements it applies to do be closer to ARIA type button. AAM spec. mappings between HTML layer and assistive tech tools... In that table there is an actual set of elements to which that ARIA role applies. Attribute which wires up everything else... makes good sense. One pushback I gave: go think about what it means for elements that may be in non-visible areas... one of the problems with ARIA (e.g. describedby) you can have something in a non-visible part of the doc still descibed... requires traversals of the content tree and the layout tree... that's still a concern. Their action is to go back to Mason and discuss A11Y feedback and define the subset of elements to which the attribute will apply.

... what we need to do ... if they scope it to specific set then it comes back to us to debate whether ... from a A11Y pov ...

Lea: it still makes for a less nice API... having a separate element would make markup more readable... would allow for easier use on JS side.

... having to pick which elements would be appropriate .. in most cases you just want a simple container.

Rossen: if you want to redesign these UI behaviours then it's a primitive you need.

Lea: you'd still have a pick a DIV to put the attributes ... to create e.g. a toast. Are there any use cases where you woulnd't use a DIV?

Peter: custom elements.

Rossen: also the fact that showPopUp and hidePopUp bound to attribute... what if element a has showpopup and element b... they had some response to this concern...

Lea: even if you scope to specific elements they produce a global namespace.. they all need to have popup prefixes... seems less elegant than a separate element. Balancing the concerns on both sides my pref would be a separate element...

Peter: concern about poluting the namespace. There is only one attribute popop that makes something a popup.

Lea: a lot of metatdata attributes...

Peter: i don't see anything other than popup in the current doc that goes on the popup itself.

Rossen: yes...

Peter: others that come into play like autofocus...

Lea: in the API side there's showpopup and hidepopup methods...

Peter: they only get added to an element when it has a popup attribute.

Rossen: yes.

Peter: any examples elsewhere of attributes that add or remove methods?

Rossen: yes i was asking that as well.

Peter: seems weird.

Lea: in every other case you'd have throw or return emtpy values if they don't apply.

Peter: methods added to element that takes the popup element. .. no comon bases class.

Rossen: right.

Peter: just for clarity it means if DIV can take popup attribute then all DIVs will have those methods.

Lea: which leads me back to the proposal of having it be an element. Better for A11Y. No precedent for this. THer's no dialog attribute hung off DIVs...

Rossen: we suggested we didn't want an element.

Lea: we had concerns but upon seeing the alternative it's worse.

Rossen: maybe we should ping Mason to have a higher bandwidth meeting? We should invite him and others... they have subsequent proposals chaining on this. I will reach out.

Peter: some responses to your last feedback, Lea.

Lea: they pointed us to the OpenUI document.. have not finished reading.

Rossen: what was the point?

Lea: they see being a popup as being a trait in same way that index is a trait of a tab element...

Rossen: not sure I agree.

Lea: I also had trouble seeing that reasoning.

Rossen: maybe we should get on a call with them?

Lea: I think that would be helpful. To have a proper breakout about this.

Rossen: I think they will be amendable to this...

Dan: I suggest a separate call at a timezone that makes more sense to the group involved.

Rossen: I will reach out.

Peter: attribute argument makes more sense to me if elements that are popups also are displayed in flow - but I don't think that's the use case here. So doesn't fit with tabindex or conteeditable.

Rossen: next thing they want to bring forward is selectelement... What you're saying (peter) makes total sense.

Peter: Suggest using the breakout B timeslot.

Lea: difficult for me.

Lea: last time they pointed to a document saying why they made this an attirubte...

Rossen: I will set it up.

Rossen: I don't have an opinion stronger than before... For myself I'm convinced that the attribute approach makes more sense given the disruption that elements can cause...

Lea: the use cases where this is a problem are also use cases where all you want is to place something on the top-layer, you don't need any of the other popup behaviors in those cases it seems. In most other cases popup is used as a container, with <div popup>.

Rossen: the disruptive behaviour that the element solution has walked me back from that idea... we don't design features that work for a majority of use cases and have known bad effects. This is an example of that - it has known bad effects. I'm happy to let them continue pursuing this. However I'm still missing the a11y point they were making. I'm willing to believe they are taking a11y seriously due to the people involved.

Dan: If we close, we should emphasize the a11y concerns and make sure they are addressed. Are we ok to close?

Lea: I have strong reservations about this approach but if no others do, I'm not gonna hold it back.

Peter: I still have reservations about the top layer behaviour. Painting order? Designer view of top layer vs User Agent top layer. One at a time? Does it close other things that are already in the top layer?

Lea: Right now, if I understood Mason Freed correctly, things in the top layer are painted in the order they are added". There is only one top-layer, the UA one. The point about the dev layer was an argument against specifying top-layer-edness in CSS, that then the UA would need another top-layer, to override the author top-layer. Though I'm not quite sure why that is specific to the CSS syntax, if authors use the popup attribute all over the place, won't the UA still need to override this somehow?

... It seems like some of these use cases are conceptually popups and some are "I just want to put this element on the top-layer". If popup is the only way to put something on the top-layer, absolutely it should not be an element! But it seems to me there is a fundamental difference between a more typical popup, e.g. a dropdown, a menu etc, and a random element that we want to show above all others for some reason (e.g. slider over video) ... if popup needs to account for all of these orthogonal concepts then that makes for a clumsy API. If placing elements on the top-layer can be done outside of popup, then popup has a more restricted set of use cases to serve and can be "smarter".

Dan: I'm trying to figure out how this won't cause a huge mess from a user perspective. If you have multiple.. if you have ads and other 3p content in the page, isn't there going to be an arms race to see who can get on the top layer first and obliterate the other top layer..

Lea: z-index: 9999 problem all over again. Not sure using an attribute is going to fix that

Peter: Yeah, I don't buy the argument that the popup api avoids the z-index problem. The whole notion of top-layer feels underspecified and undefined

Rossen: and not necessary as part of this feature/behaviour?

Peter: agree. I'm fine with popup being an attribute for now although I agree with Lea's point that once we decouple everything the attribute argument makes less sense. But first I think the top layer behaviour should be decoupled from the top layer element. Describing behaviour, triggers pseudoclasses. How something renders, what layer it renders on, should be defined completely in css. we can have all the other discussions about that. The notion of layers needs to be better thought out and defined - done independantly in CSS. (I don't think it should be done via position or display, but a separate property. I think we should do this as part of a bigger project to fix the z-index problem. z-index acts within a layer, and let that be author defined.. it's a separate discussion.)

Dan: sounds like a bag of feedback... what can we leave in the issue? Can we say we're okay with the attribute thing and say we have other concerns? And we'll work on documenting them?

Peter: [will post a response]

Lea: I pinged Rossen on slack. I've spent time looking at this and replying with my own feedback. They want a response that reflects TAG consensus.

Peter: there was still a bunch of pushback on element vs attribute. I'm convinced that attribute is fine. Maybe at some point in the future it makes sense to have an element as well but I thinka ttribute is the right direction. I do agree that I don't believe the popup should be controlling the top layerness of it - that should be controlled by CSS. The attribute should just control whether open and close pseudoclasses are being applied.

Lea: that's the point I'm making.. they said I didn't read the document. The fundamental disconnect here, why some people see it as trait vs identity of element, is that their explainer is inconsistent in this. They talka bout popups sometimes as if their main thing si being at the top layer. The example they gave of a slider that is on top of a video, the only thing that slider needs is being at the top layer - no other behaviours of popups. I don't see why it's described as a popup. And the tr example as well. I'm unclear why you'd want to put the table row at the top layer to highlight it. You don't need dismiss, ARIA roles, you don't need all the other stuff that come with a popup - just some way to style an element for being at the top layer. If we separate these concepts, an element being at the top layer doesn't need to be a popup.. then it becomes a nice package of separate behaviours...

Peter: there are other examples, tab index.. there are other examples of popupness that are orthogonal to being top layer, top layer is not required and shouldn't be tied to that. But it is a convenient mechanism of managing state. Being able to assign that behaviour to other elements is useful.

Dan: we just need Rossen.. Peter can pipe up on the issue?

Peter: I agree with part of it. Can chime on the CSS presentational aspects of it. Don't know Rossen's opinion on that yet. I don't know if we have consensus on attribute vs element. Not sure popup is even the right name for it any more, especially if it's just the behaviour of being open or closed. Some of their examples are menus that slide in from the side. It's the same as a details element, you're giving that behaviour to any random element.

Dan: makes me think about developer confusion. If we're naming something in a confusing way and say use popup for this but it's not actually a popup that's going to be one more thing where people say just use it but don't worry about the name...

Lea: it's now popover. popup clashed with other parts of the web platform. iframe sandbox keyword, allowpopups, unrelated - about window.open.

Dan: maybe we can get Rossen's feedback by plenary and discuss more

Peter: agreeing and agreeing.

Peter: if CSS has a formal notion of rendering layers ... no reason why one shouldn't be reserved. I think CSS wg hasto have a discussion about rendering layers.

Rossen: is there an issue?

Lea: worried they just decided not to do this in CSS by discussing in OpenUI without ever bringing it to the CSS wg....

Rossen: we can help build that bridge.

Lea: https://www.foodnetwork.com/recipes/ina-garten/popovers-recipe-1914814

Dan: can someone in TAG who is part of CSS open this issue?

Lea: i can.

Rossen: i think this is a good idea.

Rossen finds a relevant CSS issue which may already covers this

rossen to write comment

Rossen: approaching closure?

Lea: last time we were discussing this we had lack of consensus. Concerns.. posted minutes..

Dan: a few comments since..

Lea: oh no did we not post the minutes?

Rossen: what are you not still agreeing with?

Peter: I don't think the popup should be controlling whether something is presenting in the top layer - should be done by CSS. It should only control the psuedoclasses, and rendering is controlled by css. We need to add additional properties to css to codify the notion of a top layer, maybe create user defineable layers to fix the z-index problem.

Lea: what Peter said. And also, once you can control top-layeredness through CSS, the problems with having popup as a separate element disappear. All of the problems are around making an element on the top layer without requiring any of the other behaviours of popup

Rossen: did you propose this?

Lea: I have tried to make this point. It's minuted previously. I don't want to hold this up.

Rossen: so no engagement with them?

<blockquote> Hi - we discussed in our plenary call [on 11-2](https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/10-31-minutes.md#the-popup-api---leaverou-atanassov-1) - discussion includes some thoughts from @LeaVerou @atanassov and @plinss. Concerns center around what is and is not controlled by CSS and whether popup/popover should be the only way to place an element on the top-layer. Once you can control "top layered ness" as a CSS property, the use cases that prevent this from being an element are easily dealt with. </blockquote>

Dan: Webkit "support" as of Dec 21.

Peter: I have concerns over top layer...

Lea: same... Maybe we should close and say "satisfied with concerns"?

Peter: I'm not happy with that - who is defining top layer and where is that happening?

Rossen: in the fullscreen spec? https://fullscreen.spec.whatwg.org/#top-layer

Peter: i'm not happy with top layer being defined without participation of the CSS wg.

Rossen: curious if we have it reflected anywhere?

Peter: they're monkey-patching CSS and not involving CSS wg in the design.

Lea: yes, agree.

Peter: i don't think it's been discussed in CSS wg... but I don't recall a serious conversation about what it is...

Dan: maybe ask Chris H. in our issue?

Dan: bumps to early Jan

Peter: ... main thing I recall being contentious here was the control over top layer ... are we ok with everything else?

Lea: there were some pushback on adding this on random HTML elements... Maybe that ship has sailed.

Peter: my thoughts - maybe close this as satisfied with concerns and say we think CSS should control the top layer and we will ask CSS wg to discuss this?

Lea: agree.

notes Rossen off this week

Peter: should we punt to next week?

Peter: would want some commitment that CSS wg will working on that.

punted to next week

debate over whether it's appropriate in this case for the requestor to close their own review

Dan: I don't think this is withdrawn. Withdrawn means the requestor halted work or refactored ...

Peter: unsatisfied?

Lea: we have concerns of the whole design of this.

Peter: my largest outstanding concern is the whole top layer design... The rest of it - whether it's an element or an attribute - i see their point... I think this could be brought to Chris Harrelson.

Lea: to be fair this has been open for a long time - i do see their point from that PoV.

Peter: I hear you.

Dan: is there multi-implementer support as the requestor has stated?

Tess: is the issue with the top layer in general, or popover specifically?

Peter: i think top layer is not well thought out... not suitable for popover.

Tess: it was thrown together for Dialog element and got used for fullscreen and now popover. It's been around for a long time. I think complaining to popove people - it might not be the right audience. Better they build on something that exists than to invent a bespoke thing.

Peter: i want top layer to be part of css. The part of toplayer in the html spec i'm fine with. But CSS group needs.

Tess: I think it would be reasonable to say "...you opened the issue - please don't close it... we prefer to be the ones who close issues..." and "this is the 3rd thing that's building on toplayer... and we're concerned about its suitability... could you help..."

Dan: Including "please reference the issues Anne has referenced above."

Hadley: i think it's valuable to record our feedback for other people... having the record ... helps.

Lea: I don't think we can close it as satisfied with concerns. ... the requestor closed the review to force us to resolve. Doesn't set a good precedent.

Hadley: agree.

"Hi - there seems to be a bit of confusion here. just because it's in WHATWG it doesn't mean the review should be closed. In general TAG should be closing issues with our own process. We're going to go ahead and re-open and leave some additional feedback. We remain concerned about the toplayer spec itself which this is based on. We recognize that this isn't an issue with this spec itself. We would like to suggest that you help us work through these issues in the CSS working group (see the links from Anne above)."

Lea: I do actually have concerns with the design as well. but closing it might be the right corse of action. We've gone back and forth... our value may have been exausted.

Dan: https://github.com/w3ctag/design-reviews/issues/743#issuecomment-1476663879

Rossen: checks CSS agenda