#743: The Popover API (previously Popup)

Visit on Github.

Opened Jun 1, 2022

Wotcher TAG!

I'm requesting a TAG review of the Popup API. This is a third attempt at a TAG review for this feature; see https://github.com/w3ctag/design-reviews/issues/599 for the first, and https://github.com/w3ctag/design-reviews/issues/680 for the second.

A very common UI pattern on the Web, for which there is no native API, is "popup UI" or "popups". Popups are a general class of UI that have three common behaviors:

  1. Popups always appear on top of other page content.
  2. Popups are ephemeral. When the user "moves on" to another part of the page (e.g. by clicking elsewhere, or hitting ESC), the popup closes.
  3. Popups (of a particular type) are generally "one at a time" - opening one popup closes others.

We are proposing a set of APIs to make this type of UI easy to build.

Further details:

You should also know that...

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.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mfreed7

Security and Privacy questionnaire for TAG

2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? None. This feature does not expose any extra information to sites.

2.2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses? Yes - no new information.

2.3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them? N/A - no PII.

2.4. How do the features in your specification deal with sensitive information? N/A - no sensitive information.

2.5. Do the features in your specification introduce new state for an origin that persists across browsing sessions? No.

2.6. Do the features in your specification expose information about the underlying platform to origins? No.

2.7. Does this specification allow an origin to send data to the underlying platform? No.

2.8. Do features in this specification enable access to device sensors? No.

2.9. Do features in this specification enable new script execution/loading mechanisms? No.

2.10. Do features in this specification allow an origin to access other devices? No.

2.11. Do features in this specification allow an origin some measure of control over a user agent’s native UI? No. While pop-ups are shown in the top-layer, they cannot escape the frame bounds, and cannot be shown over the top of a UA's native UI.

2.12. What temporary identifiers do the features in this specification create or expose to the web? None.

2.13. How does this specification distinguish between behavior in first-party and third-party contexts? It does not distinguish. Pop-ups are isolated to their frame, for both 1st and 3rd party frames.

2.14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? Just fine. No exposure of private browsing state.

2.15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections? There are no known security impacts of the features in this specification.

2.16. Do features in your specification enable origins to downgrade default security protections? No.

2.17. How does your feature handle non-"fully active" documents? N/A

2.18. What should this questionnaire have asked? N/A

Discussions

Discussed Aug 1, 2022 (See Github)

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..

Discussed Aug 1, 2022 (See Github)

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.

Discussed Aug 1, 2022 (See Github)

punt to plenary

see discussion below

Comment by @torgo Aug 22, 2022 (See Github)

Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!

Comment by @mfreed7 Aug 29, 2022 (See Github)

Hi @mfreed7 sorry we should have caught this earlier but can you provide answers to the security & privacy questionnaire? Thanks!

Sorry about that - I just edited the OP to include the questionnaire. While I was there, I also linked to the in-progress spec PR.

Comment by @torgo Aug 31, 2022 (See Github)

Hi @mfreed7 thanks for that! Do you have any additional info on feedback/support from additional stakeholders (implementers)? Some additional TAG feedback incoming from our session today.

Comment by @LeaVerou Aug 31, 2022 (See Github)

Hello there, We reviewed this today in a breakout, and we are quite concerned with the amount of attributes and methods this is adding on every single element. We believe this would add a lot of additional complexity (e.g. what happens when <body> is a popup? Or when table elements are popups? Or when form elements are popups? Or replaced elements?) that is not actually required for addressing the use cases that popup is meant to address. Furthermore, this makes the API itself clunkier and more verbose, as now names need to be distinct from any other global name, not just names on the same element. It is also inconsistent with the rest of HTML, which typically defines new elements for things like that (e.g. we didn't add a dialog attribute to HTMLElement, we added a <dialog> element). We understand that this design enables some possibilities that having a separate element does not, but on balance, we don’t think the tradeoff is worth it. We would prefer to see the popup functionality as one or more separate element(s). Any attributes specified on the popup trigger (popuptoggletarget) could be global attributes.

Discussed Sep 1, 2022 (See Github)

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.

Comment by @mfreed7 Sep 2, 2022 (See Github)

Thanks for the review!

So in OpenUI we discussed this alternative (a <popup> element) at length, over roughly a year and with 10+ meetings dedicated to this specific topic. What would your solution be to the accessibility and semantic issues with that approach? (Our eventual conclusion was that there wasn’t a good solution, and the attribute approach was therefore superior. It also happens to be more powerful.) Also recall that the TAG closed my design review for <popup> based on these concerns, which is when we went in the global attribute direction.

I think we’d agree that this adds several new attributes, but only one (popup) truly confers new behavior on any element. The other two (anchor and defaultopen) simply modify that behavior. There are certainly precedents for global attributes that modify the behavior of any element, e.g. contenteditable or tabindex or even the aria-* attributes, right? Can you help me understand why this is different?

As for limiting the list of elements, we could definitely do that. However, should we restrict that list just because we don’t have a specific use case in mind right now for <input popup> or even <table popup> or <body popup>? Web developers are amazingly creative people. Of course, if there is some sort of incompatibility or reason not to support the attribute on an element, a restriction would be in order. We had such a discussion about <dialog> on https://github.com/openui/open-ui/issues/520, and decided that even there it makes sense to allow the popup attribute. How would you go about deciding which elements deserve popup support and which don’t?

Thanks again for your review! Besides the attribute vs element issue, were there any other comments on the behaviors it confers?

Hi @mfreed7 thanks for that! Do you have any additional info on feedback/support from additional stakeholders (implementers)? Some additional TAG feedback incoming from our session today.

The Gecko folks have been involved in our OpenUI discussions of the feature, and have offered some great feedback which we’ve incorporated. I wouldn’t say we have official support just yet from other implementers though.

Discussed Oct 1, 2022 (See Github)

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.

Discussed Oct 1, 2022 (See Github)

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

Rossen: I will set it up.

Discussed Oct 1, 2022 (See Github)

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]

Discussed Oct 1, 2022 (See Github)

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

Comment by @mfreed7 Oct 3, 2022 (See Github)

Just to add a bit more detail to the answer above, I've updated the explainer with a summary section detailing "why an attribute instead of an element":

https://open-ui.org/components/popup.research.explainer#why-a-content-attribute

Here is the summary paragraph of that section:

By having popup be a content attribute that purely confers behavior upon an existing element, the above problems are nicely resolved. Semantics are provided by elements, and behaviors are confered on those elements via attributes. This situation is exactly analogous to contenteditable or tabindex, which confer specific behaviors on any element. Imagine a Web in which those two attributes were instead elements: <contenteditable> and <tabindex index=0>. In that Web, many common patterns would either be very convoluted or simply not possible.

Hopefully this helps.

Comment by @mfreed7 Oct 24, 2022 (See Github)

Thanks for the great F2F discussion just now. I think we better understand your concerns, which is helpful. I hope we were able to answer at least some of them in the meeting.

As mentioned, I wrote up a fairly detailed document that goes through a nearly-complete design for each of 3 approaches: <popup> element, CSS, and Javascript. (It also talks about an old version of the content attribute.) Note that this document is somewhat rough, as it was developed while OpenUI was discussing the best fix for the problems with the <popup> element approach. However, I think it's still fairly illustrative of what the API would look like in each case.

But in particular, I want to point out the CSS version in that doc, since that's what came up during the meeting. That section details what a CSS-based pop-up API would look like, and walks through the big issues. In my view at least, the CSS approach is the most fundamentally broken of the four approaches in that doc. But take a look and see what you think.

Quick side note: your questions are all great. They're ones that the OpenUI also asked, and it took us significant conversation and exploration to get where we are today, with the content attribute approach. I'm happy to walk you through how we came to that conclusion for any piece of the API, to double-check that we made the right decisions along the way.

At this point, we'll wait here and try to address any followup questions you have. If you feel it'd be useful to have another high-bandwidth F2F to discuss this, we're more than happy.

Comment by @douglascross Oct 25, 2022 (See Github)

I'm thrilled by where this is going, having had to write an advanced popup component myself.

Has consideration been given to all the various ways a popup would get aligned to an anchor and dynamically react to the available viewport space? (much the same way as a <select> element?

This is the first time I've found myself at the cutting edge of web standards, so this is exciting.

I will be holding off replacing my popup component with native elements (or attributes) such as <dialog> because it's not sufficient. This new [popup] shows real promise.

Comment by @LeaVerou Oct 26, 2022 (See Github)

Thank you for all the background @mfreed7 and the discussion on Monday. Here are some of my thoughts (not necessarily representing TAG consensus):

The CSS approach is broken because it's trying to do everything in CSS, which is clearly not appropriate for something like this which adds functionality. A good approach would be layered: some presentational concepts may need to be added to CSS, some structural ones to HTML, and JS APIs for what remains. It is also important to decouple the concepts that a popup brings, and expose them individually as much as possible, then <popup> just becomes a nice higher level package deal. Otherwise, authors end up abusing <popup> just because they e.g. need access to the top-layer. It sounded to me like some of the use cases mentioned may have even been in that group. One of the use cases mentioned in the call was "adding the popup attribute to a <tr> to highlight it". I may be mistaken, but I didn't think highlighting an element is (conceptually) a popup. The way I see it, conceptually a popup is to present ephemeral UI near another relevant control. Dropdowns, menus, tooltips, listboxes, toasts all fall under that category. There seems to be a fundamental difference between that and highlighting an element, but perhaps I have misunderstood the user needs this is trying to address. If so, it would be good to expand the explainer with these needs.

The layered approach seems to already be largely followed, e.g. with the anchor positioning proposal. It seems to me that top-layer-ness is also a concept that belongs to CSS. Then the UA stylesheet could make sure popups and dialogs enter the top layer via something like:

dialog[open],
popup[open] {
	position: top-layer; /* or whatever */
}

The typical HTML way for adding functionality around elements is to wrap them with other elements and encapsulate the functionality in these elements. This is how <dialog> works, this is how <details> works, sectioning elements, or even custom elements. tabindex and contenteditable assign traits to existing elements (making them focusable or editable), whereas popup seems much more clearly a container-type functionality. An element is a popup, popup-edness (😀) is central to what the element is for, whereas tabindex and contenteditable do not describe the element, do not set its identity, they are essentially metadata that set certain behaviors. Indeed, the vast majority of examples I see are <div popup>.

I'm not an a11y expert, so I'd love some clarification on why the semantics of "group that contains a table" are problematic and we instead need to make the table a popup. However, if a container with a single child is problematic for a11y, it sounds like this is something that affects other elements too. What is the role of a <dialog> or <details> that contains a single table? If these are problematic, do we need to introduce some kind of role "hoisting" up the DOM tree?

The current proposal introduces the concept of a minimum role to ensure a popup is never less meaningful than at least than a group. However, a <popup> element would address this quite naturally, by having a default ARIA role of group, unless a different type is specified (or explicitly a role). Sure, you say the concept of a minimum role would help with other things too, but at least it wouldn't be needed here. I'm also wondering if we need a new ARIA role for a popup that is not something else? It doesn't seem enough to describe it with just role=group, but again, I'm not an a11y expert, just thinking out loud.

Furthermore, making <popup> an element would help you do away with warts like these:

It also allows more room for future expansion, without adding popup* attributes to divs and other random elements. And it would free up the popup attribute to be used for something else, e.g. toggling a popup (I find names like popuptoggletarget and popuphidetarget pretty hard to read or understand).

Comment by @mfreed7 Oct 28, 2022 (See Github)

Thanks for the comments! I'd really like to hear a consensus response that hopefully includes the discussion points raised in the F2F.

A good approach would be layered: some presentational concepts may need to be added to CSS, some structural ones to HTML, and JS APIs for what remains

I agree! I believe this is what we've done. The popup and popupshowtarget/etc. attributes in HTML, the :open and :closed pseudo classes in CSS, and showPopUp()/popupshow/etc in JS.

It seems to me that top-layer-ness is also a concept that belongs to CSS. Then the UA stylesheet could make sure popups and dialogs enter the top layer via something like: ...

I would recommend you please take a look at the alternatives document's CSS section. It contains exactly your position: top-layer CSS idea, and then walks through the rest of the design, and all of the problems that ensue. In particular this section about the behaviors. I don't want to re-hash all of those reasons here in this comment. As I said in the meeting, I completely see why this is a great first opinion about how this feature should work, but it just seems to really fall apart when you get into all of the details of the design.

tabindex and contenteditable assign traits to existing elements (making them focusable or editable), whereas popup seems much more clearly a container-type functionality. An element is a popup, popup-edness (😀) is central to what the element is for, whereas tabindex and contenteditable do not describe the element, do not set its identity, they are essentially metadata that set certain behaviors. Indeed, the vast majority of examples I see are <div popup>.

I think this is a core difference of opinion. The pop-up API very specifically provides presentational behaviors that can be applied to any element. The fact that something "pops up" is not central to what the element is for, at all. This is the same as the fact that whether something is "editable" does not change what the element is. An editable table cell is still a table cell, it just has a behavior that makes it editable. Here are some examples for pop-up:

  1. <dialog popup> is a dialog and has pop-up behaviors. Note that the only difference between this and a "plain" modal dialog is the behavior, particularly light-dismiss.
  2. <div role=listbox popup> is a listbox that pops up over other content and light dismisses. That same listbox without popup is still a listbox, it just doesn't pop up.
  3. <input type=range popup> is a range slider that pops up over the top. An example is a video volume slider.
  4. <tr popup> is a table row which pops up to emphasize the row. That use case in particular is impossible via a <popup> element, due to table fixup rules.

In all of these cases, the element defines what, semantically, the content is, while the popup attribute adds some nice behaviors to that element. This is 100% aligned with how tabindex or contenteditable work for all of these same examples. They add behavior to an existing element, but do not change the semantics of that element.

Also, one side note while I'm here: the API has been renamed to the "popover" API based on a naming conflict raised by the WHATWG.

Comment by @LeaVerou Oct 31, 2022 (See Github)

I'm starting to think the fundamental disconnect here is that parts of the popup/popover proposal (and even comments here) talk about top-layeredness as the main thing a popup brings and others talk about it as just one of many features a popup brings. Top-layeredness is absolutely a trait of another element and not an element "identity". However, a popup is not just an element on the top-layer, is it? It's also an element with light dismiss behaviors, that can be opened and closed through certain triggers, whose position may be anchored to another element, that comes with certain ARIA minimum roles, etc. The way I see it, there's a fundamental difference between e.g. a dropdown menu (popup) and a slider that "pops-up" over a video (which doesn't need any of these behaviors, just top-layer access). It is not great DX if developers that only need one popup behavior (e.g. top-layer or light-dismiss) need to pull in the entire "popup package" and disable features one by one (e.g. `popup="manual"). Ideally, all of these behaviors should be available separately, then popup itself can be more high level (e.g. even come with default UA styling), as it would only be used when an author needs multiple of these behaviors.

<dialog popup> is a dialog and has pop-up behaviors. Note that the only difference between this and a "plain" modal dialog is the behavior, particularly light-dismiss.

Case in point, I wonder if light dismiss should also be available separately. It seems a bit weird to make a dialog a popup just so it can have light dismiss.

<div role=listbox popup> is a listbox that pops up over other content and light dismisses. That same listbox without popup is still a listbox, it just doesn't pop up.

Conceptually, a listbox inside a popup makes just as much sense to me, if not more than the listbox popping up by itself. With the listbox itself being the popup, once you need to include a tip about the options or a validation indicator or whatnot suddenly you have to change your markup completely.

<tr popup> is a table row which pops up to emphasize the row.

Do you have an example of this kind of use case? Is it only using popup for top-layer access or also other behaviors?

I would recommend you please take a look at the alternatives document's CSS section. It contains exactly your position: top-layer CSS idea, and then walks through the rest of the design, and all of the problems that ensue.

I did read the document — that's where position: top-layer came from! That document is why I wrote that the problems with the CSS approach stem from trying to do everything in CSS. Here is a more detailed response to the points raised in that document:

A “dual class” top layer will need to be created, with <dialog> and fullscreen always above “developer” top layer elements.

I think part of this problem is actually unrelated to the exact syntax you pick. Even if <popup> or <div popup> comes with magic that places it at the top-layer, once developers start (ab)using it to put things at the top-layer, the UA will need an even higher top-layer for its own stuff. It's basically the z-index: 99999 problem in a different form, where many different components all want to be "above everything else on the page". You've already identified this in other places, since there are more than 1 ways to place things at the top-layer, so how do dialogs, popovers, and fullscreen elements interact? What about different popups that are open at the same time? You already need to have a layering order.

In order to use CSS to control top layer access, there would no longer be a way to deny or remove an element from the top layer, for example when a modal dialog or fullscreen element needs to be shown.

See above.

That precludes using a popup on top of a dialog/fullscreen.

Why? Could you please explain this a bit more?

a CSS-based approach precludes any way for the UA to “force” elements out of the top layer.

Why not? The UA can override whatever CSS it needs to.

In this approach, light dismiss and one-at-a-time behavior cannot be built into a CSS property, and must be implemented in JavaScript.

Maybe I'm not following this argument, but it does not seem like a problem at all, just a good separation of concerns. CSS would totally not be appropriate to describe light dismiss behaviors, that's why I suggested that <popup> would be a nice convenient package of a bunch of CSS and JS APIs.

Unclear how to implement the popup declarative activation feature.

Again, this assumes that if top-layeredness is defined in CSS, everything must be done in CSS. position: top-layer (or whatever syntax) would just define appearance once the popup is shown, you'd still need an open attribute or an internal state to control whether it's shown. Declarative activation would be defined in terms of modifying that state with appropriate events, and has nothing to do with CSS.

If access to the top layer was controlled via CSS, there could not be a CSS selector to select items in the top layer.

Indeed, but that's like saying "I want a selector that targets display: grid elements, i.e. why would you want to do that?

Comment by @nt1m Oct 31, 2022 (See Github)

@mfreed7 I think in theory popover as an attribute could make sense, but in practice, the style adjustments triggered by top layer sort of limit the scope of the API, and what use cases are possible with it: https://fullscreen.spec.whatwg.org/#new-stacking-layer

<input type=range popup> is a range slider that pops up over the top. An example is a video volume slider.

It seems more likely that someone wanting to achieve such use case, will create a container element with the range input in it, to work around the style adjustments.

<tr popup> is a table row which pops up to emphasize the row.

How is that possible without the table row popping up in random places? the abspos adjustment makes this impossible.

Discussed Nov 1, 2022 (See Github)

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

Discussed Nov 1, 2022 (See Github)

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>
Comment by @mfreed7 Nov 1, 2022 (See Github)

We are taking a layered approach, so these questions you’re asking make sense. This is the approach @plinss suggested at https://github.com/w3ctag/design-reviews/issues/680#issuecomment-946019920, and we agreed with it. It’s also why anchor positioning is a separate feature from popover.

However, a popup is not just an element on the top-layer, is it? It's also an element with light dismiss behaviors, that can be opened and closed through certain triggers, whose position may be anchored to another element, that comes with certain ARIA minimum roles, etc.

Yes, definitely it’s more than just top layer or light dismiss, it's a package of interrelated behaviors. That additionally includes one-at-a-time / nested popovers, declarative triggering behaviors, and a11y tree effects like adding aria-expanded. All of the things needed to truly make a "popover" without breaking accessibility or requiring tons of Javascript. As mentioned, the positioning part of your comment is covered by the separate anchor positioning proposal.

Case in point, I wonder if light dismiss should also be available separately. It seems a bit weird to make a dialog a popup just so it can have light dismiss.

That’s an interesting thing to consider for future extensions, but I don’t know of a use case where they would be separated. All the use cases we found needed both. Certainly if a use case arises in the future for an isolated "light dismiss" feature, we could explain Popover in terms of that new feature.

Do you have an example of this kind of use case? Is it only using popup for top-layer access or also other behaviors?

@scottaohara referred to one in the telecon meeting we had last week. To me, the main point to reinforce is that the approach we’re taking is a layered behavior one, so that you can use these behaviors in a variety of use cases, some of which we didn’t even think of. Similar to what you said above about top layer etc.

I did read the document — that's where position: top-layer came from! That document is why I wrote that the problems with the CSS approach stem from trying to do everything in CSS. Here is a more detailed response to the points raised in that document:

Oh ok. But that’s just what I said by “walks through the rest of the design” -- not a design that forces everything into CSS, but one that deals with the consequences of display:top-layer to see if it will work. For example, in the alternatives doc, the behaviors are provided via a set of events and some Javascript methods. It works, but it's dramatically less ergonomic.

I think part of this problem is actually unrelated to the exact syntax you pick. Even if <popup> or <div popup> comes with magic that places it at the top-layer, once developers start (ab)using it to put things at the top-layer, the UA will need an even higher top-layer for its own stuff. It's basically the z-index: 99999 problem in a different form, where many different components all want to be "above everything else on the page". You've already identified this in other places, since there are more than 1 ways to place things at the top-layer, so how do dialogs, popovers, and fullscreen elements interact? What about different popups that are open at the same time? You already need to have a layering order.

Actually, the Popover API provides access to the UA top-layer directly, and doesn't need to introduce a developer top layer. This is ultimately why it has to come with light dismiss and UA control aspects. It's also how it avoids the "z-index arms race".

I agree that you need a well-defined order in any top layer regardless. That order is enforced by this spec text (TL;DR top layer stuff renders in the order it was added to the top layer). Also, popover=auto popovers are automatically closed when something else like a modal <dialog> enters the top layer.

Another thing you could consider is two top layers, a developer one and a UA one. We considered that as well, but it has the problem that you wouldn’t be able to do stuff like showing a popover (like a select menu, in the developer top layer) on top of a modal dialog (in the UA top layer). That's a fairly common use case. Also see this CSSWG issue which is related.

Why? Could you please explain this a bit more?

Because of the developer top-layer vs UA top-layer issue I mentioned just above. By the way, I do think it would be fine to consider a developer top-layer (lots of discussion here), it’s just that it has to be lower than the UA top layer. And that precludes a number of common use cases, including most of the ones the Popover API aims to solve.

Why not? The UA can override whatever CSS it needs to.

Ok, but once the UA kicks a popover out of the top layer, the only way to get it back in would be to do something that causes the UA to stop forcing it out, such as calling a JS API that does it. And then you end up with grouping “light dismiss” and integrated JS/event stuff like the alternatives doc describes. This is different than the original way it might have arrived in the top layer via a regular CSS rule like position:top-layer.

—----

@mfreed7 I think in theory popover as an attribute could make sense, but in practice, the style adjustments triggered by top layer sort of limit the scope of the API, and what use cases are possible with it: https://fullscreen.spec.whatwg.org/#new-stacking-layer

@nt1m See above for more context, but the positioning is being proposed as a separate API: Anchor Positioning. I believe it very nicely "solves" the style adjustments problem you bring up. The popover API provides the "on top" behaviors (and position:fixed as you mention) and the anchor positioning API allows a popover to be easily positioned relative to an appropriate anchor element. Is there a use case that you don't think is adequately handled by a combination of Popover and Anchor Pos?

Comment by @torgo Nov 14, 2022 (See Github)

Hi - we discussed in our plenary call on 11-2 - 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.

Comment by @nt1m Nov 14, 2022 (See Github)

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.

The nice thing about JS controlling the top layer is that it can enforce restrictions that allow the painting order to be somewhat sensical whereas with a CSS property, you can't really do so. As it stands, what can push to top layer is requestFullscreen() and dialog.showModal(), and the painting order is enforced by the ordering of the calls (not the ordering of the elements in the DOM!), which works out quite nicely! And there are restrictions to prevent weird edge cases, for instance, you can't fullscreen a <dialog> element.

I would oppose allowing CSS to move things into the top layer, because you allow such a mechanism, the stacking nature of the top layer no longer works out (which position do we use for a CSS-top layer element in the stack?), and problems similar to z-index arise again.

I think for popover you also need a JS call (showPopover) in order to push to the top layer, which works out great I think, but yeah I would definitely be concerned if just using the popover attribute added it to the top layer.

Comment by @mfreed7 Nov 16, 2022 (See Github)

+1 to @nt1m's response. As to this part:

I think for popover you also need a JS call (showPopover) in order to push to the top layer, which works out great I think, but yeah I would definitely be concerned if just using the popover attribute added it to the top layer.

You're exactly right that there's an explicit action (either .showPopover() or user-click on an invoking element), which means there's a well defined point at which the Popover is added to the top layer.

From the discussion:

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?

I don't understand this question. This is basically what the Popover API does. The behaviors include managing the top layer, and allowing 1) proper ordering of things in the top layer, and 2) being able to kick them out when needed.

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.. z-index: 9999 problem all over again. Not sure using an attribute is going to fix that 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

Can you be more specific about this concern? This is essentially what the Popover API does, in combination with the (pre-existing) top-layer concept. Since it's a stacking layer in the document, 3p content is constrained to the iframe it's in. The z-index: 999 problem is precisely what is avoided by having only one top layer, and having well-specified behaviors around adding and removing from that top layer.

On the "top layer feels underspecified and undefined", can you be more specific? Top layer is defined right here, as:

The top layer is an ordered set of elements, rendered in the order they appear in the set. The last element in the set is rendered last, and thus appears on top.

If there's something missing from this spec, let's clarify it!

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

We're taking a11y very seriously, and we're committed to making Popover accessible by default. We've pulled out some pieces of the API (e.g. popover=hint) precisely because we don't yet know how to make them accessible.

Can we say we're okay with the attribute thing and say we have other concerns?

It sounds like generally, the feedback is:

  1. You'd like more documentation or explanation of the top layer concept. If you let me know what's missing, I'm happy to work on that.
  2. You'd still like a "CSS way" to add things to the top layer. If somehow this were specified in the future, it could be used to explain how Popover works today.
  3. You'd like to make sure we're taking a11y seriously. I promise we are, but let me know if there are specific concerns, and I'll make sure we address them.
Comment by @atanassov Nov 17, 2022 (See Github)

@mfreed7, a relevant conversation to your points 1 & 2 that lacks traction with the CSSWG is https://github.com/w3c/csswg-drafts/issues/4998. We thought that if your were to address it, it will allow for quicker progress here.

Comment by @chrishtr Nov 17, 2022 (See Github)

@mfreed7, a relevant conversation to your points 1 & 2 that lacks traction with the CSSWG is w3c/csswg-drafts#4998. We thought that if your were to address it, it will allow for quicker progress here.

One note: issue CSSWG issue 4998 is really a spec refactoring task, not a lack of definition in the previous spec location. Still worth doing of course.

Comment by @torgo Nov 18, 2022 (See Github)

webkit standards position: https://github.com/WebKit/standards-positions/issues/74#issuecomment-1311566112

Comment by @chrishtr Nov 18, 2022 (See Github)

One note: issue CSSWG issue 4998 is really a spec refactoring task, not a lack of definition in the previous spec location. Still worth doing of course.

In addition, I have reviewed the top layer definition in the past multiple times, looking for any potential problem. I found it well defined and logical, even with respect to all the ways scrolling, z-index and every possible visual effect on elements, including the root element. So I do think this is a robust and well-defined concept that we can safely build upon.

Discussed Dec 1, 2022 (See Github)

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

Comment by @plinss Dec 21, 2022 (See Github)

I still have concerns about an active popover being automatically placed in the top layer, I feel this is something that should be controlled by CSS and can happen by default via the UA stylesheet.

@chrishtr I also have strong concerns that while top layer may be well defined, I don't believe that it's being defined in the right place. The full screen spec is monkey-patching CSS. The top layer design should be brought to the CSSWG and discussed there. The resulting design should be folded into a CSS spec and referenced from full screen.

Comment by @nt1m Dec 21, 2022 (See Github)

I feel this is something that should be controlled by CSS

I'm not involved in the popover API, but again I strongly oppose this idea for the reasons stated in https://github.com/w3ctag/design-reviews/issues/743#issuecomment-1314204961

In a CSS-controlled top layer, what controls the z-order within the top layer of the elements? It's going to be completely arbitrary. It will pretty much behave the same as z-index: MAX_VALUE and have the same problems.

For consistency with other things in the top layer at the moment, perhaps a better way is a JS call that doesn't push to the top layer.

Comment by @annevk Dec 21, 2022 (See Github)

@plinss that's been brought up repeatedly, but nobody picked it up thus far:

I've been asking for the CSS WG to take that over since I started working on Fullscreen a decade ago or so. Not exactly my area of expertise.

Comment by @mfreed7 Jan 10, 2023 (See Github)

I feel this is something that should be controlled by CSS

I'm not involved in the popover API, but again I strongly oppose this idea for the reasons stated in #743 (comment)

In a CSS-controlled top layer, what controls the z-order within the top layer of the elements? It's going to be completely arbitrary. It will pretty much behave the same as z-index: MAX_VALUE and have the same problems.

+1. The top layer is an ordered set, so it depends on the order that things are placed there. I'm not sure you'll be able to re-define top-layer as a feature determined by CSS, because it won't play nicely with existing things like dialog and fullscreen. (See this issue for ways to animate top layer status via CSS.)

Discussed Feb 1, 2023 (See Github)

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

Discussed Mar 1, 2023 (See Github)

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

Comment by @mfreed7 Mar 17, 2023 (See Github)

Quick followup on this TAG review: the spec has landed in WHATWG with multiple implementer support. https://html.spec.whatwg.org/multipage/popover.html

I'm going to close this design review. Thanks for all of the comments!

Comment by @torgo Mar 20, 2023 (See Github)

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).

Comment by @mfreed7 Mar 20, 2023 (See Github)

Oops, sorry about that! Github gave me a shiny "close this issue" button, so I pressed it. I won't do that in the future. And yes, I'll participate in the top layer discussions as needed.

Comment by @atanassov Mar 20, 2023 (See Github)

Thank you @mfreed7. Ideally we can talk about it this Wednesday during the csswg vf2f.