From c3d34b0591621b6493e3108b28b8da85d010e00d Mon Sep 17 00:00:00 2001 From: Mason Freed Date: Fri, 28 Oct 2022 11:41:46 -0700 Subject: [PATCH] Rename `popup` to `popover` globally This follows the recent [OpenUI resolution](https://github.com/openui/open-ui/issues/627#issuecomment-1293918937) to rename the API. --- .../pages/popup/popup.research.explainer.mdx | 434 +++++++++--------- 1 file changed, 219 insertions(+), 215 deletions(-) diff --git a/research/src/pages/popup/popup.research.explainer.mdx b/research/src/pages/popup/popup.research.explainer.mdx index ee85f1ae6..043a09960 100644 --- a/research/src/pages/popup/popup.research.explainer.mdx +++ b/research/src/pages/popup/popup.research.explainer.mdx @@ -1,12 +1,12 @@ --- menu: Proposals -name: Pop Up API (Explainer) +name: Popover API (Explainer) path: /components/popup.research.explainer pathToResearch: /components/popup.research --- - [@mfreed7](https://github.com/mfreed7), [@scottaohara](https://github.com/scottaohara), [@BoCupp-Microsoft](https://github.com/BoCupp-Microsoft), [@domenic](https://github.com/domenic), [@gregwhitworth](https://github.com/gregwhitworth), [@chrishtr](https://github.com/chrishtr), [@dandclark](https://github.com/dandclark), [@una](https://github.com/una), [@smhigley](https://github.com/smhigley), [@aleventhal](https://github.com/aleventhal) -- October 18, 2022 +- October 28, 2022 Please also see the [WHATWG html spec PR for this proposal](https://github.com/whatwg/html/pull/8221). @@ -17,10 +17,10 @@ Please also see the [WHATWG html spec PR for this proposal](https://github.com/w - [Background](#background) - [Goals](#goals) - [See Also](#see-also) - - [Pop-Up vs. Dialog](#pop-up-vs-dialog) + - [Popover vs. Dialog](#popover-vs-dialog) - [API Shape](#api-shape) - [HTML Content Attribute](#html-content-attribute) - - [Showing and Hiding a Pop-up](#showing-and-hiding-a-pop-up) + - [Showing and Hiding a Popover](#showing-and-hiding-a-popover) - [IDL Attribute and Feature Detection](#idl-attribute-and-feature-detection) - [Events](#events) - [Focus Management](#focus-management) @@ -32,8 +32,8 @@ Please also see the [WHATWG html spec PR for this proposal](https://github.com/w - [Accessibility / Semantics](#accessibility--semantics) - [Disallowed elements](#disallowed-elements) - [Example Use Cases](#example-use-cases) - - [Generic Pop-up (Date Picker)](#generic-pop-up-date-picker) - - [Generic Pop-up (`` listbox example)](#generic-pop-up-selectmenu-listbox-example) + - [Generic Popover (Date Picker)](#generic-popover-date-picker) + - [Generic Popover (`` listbox example)](#generic-popover-selectmenu-listbox-example) - [Manual](#manual) - [Additional Considerations](#additional-considerations) - [Exceeding the Frame Bounds](#exceeding-the-frame-bounds) @@ -48,10 +48,10 @@ Please also see the [WHATWG html spec PR for this proposal](https://github.com/w # Background -A very common UI pattern on the Web, for which there is no native API, is "pop up UI" or "pop-ups". Pop-ups are a general class of UI that have three common behaviors: - 1. Pop-ups always appear **on top of other page content**. - 2. Pop-ups are **ephemeral**. When the user "moves on" to another part of the page (e.g. by clicking elsewhere, or hitting ESC), the pop-up hides. - 3. Pop-ups (of a particular type) are generally **"one at a time"** - opening one pop-up closes others. +A very common UI pattern on the Web, for which there is no native API, is "popover UI", also sometimes called "popovers", "pop up UI", or "popovers". Popovers are a general class of UI that have three common behaviors: + 1. Popovers always appear **on top of other page content**. + 2. Popovers are **ephemeral**. When the user "moves on" to another part of the page (e.g. by clicking elsewhere, or hitting ESC), the popover hides. + 3. Popovers (of a particular type) are generally **"one at a time"** - opening one popover closes others. This document proposes a set of APIs to make this type of UI easy to build. @@ -66,13 +66,13 @@ Here are the goals for this API: * Allow these top layer elements to reside at semantically-relevant positions in the DOM. I.e. it should not be required to re-parent a top layer element as the last child of the `document.body` simply to escape ancestor containment and transforms. * Include an appropriate user input and focus management experience, with flexibility to modify behaviors such as initial focus. * **Accessible by default**, with the ability to further extend semantics/behaviors as needed for the author's specific use case. -* Avoid developer footguns, such as improper stacking of dialogs and pop-ups, and incorrect accessibility mappings. +* Avoid developer footguns, such as improper stacking of dialogs and popovers, and incorrect accessibility mappings. * Avoid the need for any Javascript for most common cases. * Easy animation of show/hide operations. ## See Also -See the [original `` element explainer](https://open-ui.org/components/popup.research.explainer), and also the comments on [Issue 410](https://github.com/openui/open-ui/issues/410) and [Issue 417](https://github.com/openui/open-ui/issues/417). See also [this CSSWG discussion](https://github.com/w3c/csswg-drafts/issues/6965) which has mostly been about a CSS alternative for top layer. +See the [original `` element explainer](https://open-ui.org/components/popup.research.explainer-v1), and also the comments on [Issue 410](https://github.com/openui/open-ui/issues/410) and [Issue 417](https://github.com/openui/open-ui/issues/417). See also [this CSSWG discussion](https://github.com/w3c/csswg-drafts/issues/6965) which has mostly been about a CSS alternative for top layer. This proposal was discussed in OpenUI on [Issue 455](https://github.com/openui/open-ui/issues/455), which was closed as [resolved](https://github.com/openui/open-ui/issues/455#issuecomment-1050172067). In WHATWG/html, [Issue 7785](https://github.com/whatwg/html/issues/7785) tracks the addition of this feature. @@ -80,30 +80,30 @@ There have been **many** discussions and resolutions at OpenUI of various aspect There have been three TAG reviews for this set of functionality: [#599](https://github.com/w3ctag/design-reviews/issues/599) (closed waiting for anchor positioning), [#680](https://github.com/w3ctag/design-reviews/issues/680) (closed recommending change from `` to `popup` attribute), [#743](https://github.com/w3ctag/design-reviews/issues/743) (open). -## Pop-Up vs. Dialog +## Popover vs. Dialog -A natural question that [commonly arises](https://github.com/openui/open-ui/issues/581) is: what's the difference between a "pop-up" and a "dialog"? There are two ways to interpret this question: +A natural question that [commonly arises](https://github.com/openui/open-ui/issues/581) is: what's the difference between a "popover" and a "dialog"? There are two ways to interpret this question: 1. What are the difference between these general UX patterns and words? - 2. What are the technical implementation differences between `
` and ``? + 2. What are the technical implementation differences between `
` and ``? -In both cases, an important distinction needs to be made between **modal** and **non-modal** (or **modeless**) dialogs. With a **modal** dialog, the rest of the page (outside the dialog) is rendered **`inert`**, so that only the contents of the dialog are interactable. Importantly, a pop-up is **non-modal**. Almost by definition, a pop-up is not permanent: it goes away (via light dismiss) when the user changes their attention to something else, by clicking or tabbing to something else. For these reasons, if the dialog in question needs to be **modal**, then the `` element is the way to go. +In both cases, an important distinction needs to be made between **modal** and **non-modal** (or **modeless**) dialogs. With a **modal** dialog, the rest of the page (outside the dialog) is rendered **`inert`**, so that only the contents of the dialog are interactable. Importantly, a popover is **non-modal**. Almost by definition, a popover is not permanent: it goes away (via light dismiss) when the user changes their attention to something else, by clicking or tabbing to something else. For these reasons, if the dialog in question needs to be **modal**, then the `` element is the way to go. -Having said that, dialogs can also be **non-modal**, and pop-ups can be set to not light-dismiss (via **`popup=manual`**). There is a significant area of overlap between the two Web features. Some use cases that lie in this area of overlap include: +Having said that, dialogs can also be **non-modal**, and popovers can be set to not light-dismiss (via **`popover=manual`**). There is a significant area of overlap between the two Web features. Some use cases that lie in this area of overlap include: 1. "Toasts" or asynchronous notifications, which stay onscreen until dismissed manually or via a timer. 2. Persistent UI, such as teaching-UI, that needs to stay on screen while the user interacts with the page. -3. Custom components that need to "manually" control pop-up behavior. +3. Custom components that need to "manually" control popover behavior. -Given these use cases, it's important to call out the technical differences between a non-modal `` and a `
`: +Given these use cases, it's important to call out the technical differences between a non-modal `` and a `
`: -- A `
` is **in the top layer**, so it draws on top of other content. The same is not true for a non-modal ``. This is likely the most impactful difference, as it tends to be difficult to ensure that a non-modal `` is painted on top of other page content. -- A `` element always has **`role=dialog`**, while the `popup` attribute can be applied to the **most-semantically-relevant HTML element**, including the `` element itself: ``. -- The pop-up API comes with some **"nice to have's"**: - - pop-ups are easy to animate both the show and hide transitions, via pure CSS. In contrast, JS is required in order to animate `dialog.close()`. - - pop-ups work with the invoking attributes (e.g. `popuptoggletarget`) to declaratively show/hide them with pure HTML. In contrast, JS is required to show/close a ``. - - pop-ups fire both a "show" and a "hide" event. In contrast, a `` only fires `cancel` and `close`, but no event is fired when it is shown. +- A `
` is **in the top layer**, so it draws on top of other content. The same is not true for a non-modal ``. This is likely the most impactful difference, as it tends to be difficult to ensure that a non-modal `` is painted on top of other page content. +- A `` element always has **`role=dialog`**, while the `popover` attribute can be applied to the **most-semantically-relevant HTML element**, including the `` element itself: ``. +- The popover API comes with some **"nice to have's"**: + - popovers are easy to animate both the show and hide transitions, via pure CSS. In contrast, JS is required in order to animate `dialog.close()`. + - popovers work with the invoking attributes (e.g. `popovertoggletarget`) to declaratively show/hide them with pure HTML. In contrast, JS is required to show/close a ``. + - popovers fire both a "popovershow" and a "popoverhide" event. In contrast, a `` only fires `cancel` and `close`, but no event is fired when it is shown. -For the above reasons, it seems clear that for use cases that need a **non-modal** dialog which has pop-up behavior, a `` (with the most appropriate value for the `popup` attribute) should be preferred. Importantly, if the use case is **not** meant to be exposed as a "dialog", then another (non-``) element should be used with the `popup` attribute, or a generic `
` should be used with the appropriate role added. +For the above reasons, it seems clear that for use cases that need a **non-modal** dialog which has popover behavior, a `` (with the most appropriate value for the `popover` attribute) should be preferred. Importantly, if the use case is **not** meant to be exposed as a "dialog", then another (non-``) element should be used with the `popover` attribute, or a generic `
` should be used with the appropriate role added. # API Shape @@ -111,105 +111,105 @@ This section lays out the full details of this proposal. If you'd prefer, you ca ## HTML Content Attribute -A new content attribute, **`popup`**, controls both the top layer status and the dismiss behavior. There are several allowed values for this attribute: +A new content attribute, **`popover`**, controls both the top layer status and the dismiss behavior. There are several allowed values for this attribute: -* **`popup=auto`** - A top layer element following "Auto" dismiss behaviors (see below). -* **`popup=manual`** - A top layer element following “Manual” dismiss behaviors (see below). +* **`popover=auto`** - A top layer element following "Auto" dismiss behaviors (see below). +* **`popover=manual`** - A top layer element following “Manual” dismiss behaviors (see below). -Additional values for the `popup` attribute may become available in the future. +Additional values for the `popover` attribute may become available in the future. -So this markup represents pop-up content: +So this markup represents popover content: ```html -
I am a pop-up
+
I am a popover
``` -As written above, the `
` will be rendered `display:none` by the UA stylesheet, meaning it will not be shown when the page is loaded. To show the pop-up, one of several methods can be used: [declarative triggering](#declarative-triggers), [Javascript triggering](#javascript-trigger), or [page load triggering](#page-load-trigger). +As written above, the `
` will be rendered `display:none` by the UA stylesheet, meaning it will not be shown when the page is loaded. To show the popover, one of several methods can be used: [declarative triggering](#declarative-triggers), [Javascript triggering](#javascript-trigger), or [page load triggering](#page-load-trigger). -Additionally, the `popup` attribute can be used without a value (or with an empty string `""` value), and in that case it will behave identically to `popup=auto`: +Additionally, the `popover` attribute can be used without a value (or with an empty string `""` value), and in that case it will behave identically to `popover=auto`: ```html -
I am a pop-up
-
I am also an "auto" pop-up
-
So am I
+
I am a popover
+
I am also an "auto" popover
+
So am I
``` -For convenience and brevity, the remainder of this explainer will use this boolean-like syntax in most cases, e.g. `
`. +For convenience and brevity, the remainder of this explainer will use this boolean-like syntax in most cases, e.g. `
`. -## Showing and Hiding a Pop-up +## Showing and Hiding a Popover -There are several ways to "show" a pop-up, and they are discussed in this section. When any of these methods are used to show a pop-up, it will be made visible and moved (by the UA) to the [top layer](https://fullscreen.spec.whatwg.org/#top-layer). The top layer is a layer that paints on top of all other page content, with the exception of other elements currently in the top layer. This allows, for example, a "stack" of pop-ups to exist. +There are several ways to "show" a popover, and they are discussed in this section. When any of these methods are used to show a popover, it will be made visible and moved (by the UA) to the [top layer](https://fullscreen.spec.whatwg.org/#top-layer). The top layer is a layer that paints on top of all other page content, with the exception of other elements currently in the top layer. This allows, for example, a "stack" of popovers to exist. ### Declarative Triggers -A common design pattern is to have a button which makes a pop-up visible. To facilitate this pattern, and avoid the need for Javascript in this common case, three content attributes (`popuptoggletarget`, `popupshowtarget`, and `popuphidetarget`) allow the developer to declaratively toggle, show, or hide a pop-up. To do so, the attribute's value should be set to the idref of another element: +A common design pattern is to have a button which makes a popover visible. To facilitate this pattern, and avoid the need for Javascript in this common case, three content attributes (`popovertoggletarget`, `popovershowtarget`, and `popoverhidetarget`) allow the developer to declaratively toggle, show, or hide a popover. To do so, the attribute's value should be set to the idref of another element: ```html - -
Pop-up content
+ +
Popover content
``` -When the button in this example is activated, the UA will call `.showPopUp()` on the `
` element if it is currently hidden, or `hidePopUp()` if it is showing. In this way, no Javascript will be necessary for this use case. +When the button in this example is activated, the UA will call `.showPopover()` on the `
` element if it is currently hidden, or `hidePopover()` if it is showing. In this way, no Javascript will be necessary for this use case. -If the desire is to have a button that only shows or only hides a pop-up, the following markup can be used: +If the desire is to have a button that only shows or only hides a popover, the following markup can be used: ```html - - - -
Pop-up content
+ + + +
Popover content
``` Note that all three attributes can be used together like this, pointing to the same element. However, using more than one triggering attribute on **a single button** is not recommended. -When the `popuptoggletarget`, `popupshowtarget`, or `popuphidetarget` attributes are applied to an activating element, the UA may automatically map this attribute appropriate `aria-*` attributes, such as `aria-haspopup`, `aria-describedby` and/or `aria-expanded`, in order to ensure accessibility. There will need to be further discussion with the ARIA working group to determine the exact ARIA semantics, if any, are necessary. +When the `popovertoggletarget`, `popovershowtarget`, or `popoverhidetarget` attributes are applied to an activating element, the UA may automatically map this attribute appropriate `aria-*` attributes, such as `aria-haspopup`, `aria-describedby` and/or `aria-expanded`, in order to ensure accessibility. There will need to be further discussion with the ARIA working group to determine the exact ARIA semantics, if any, are necessary. -These attributes are only supported on buttons (including ` - + + ...date picker contents... - + ``` -## Generic Pop-up (`` listbox example) +## Generic Popover (`` listbox example) ```html -
+
- + ``` @@ -590,14 +590,14 @@ This section contains several HTML examples, showing how various UI elements mig ```html
- +
``` @@ -609,37 +609,37 @@ This section contains several HTML examples, showing how various UI elements mig ## Exceeding the Frame Bounds -Allowing a pop-up/top-layer element to exceed the bounds of its containing frame poses a serious security risk: such an element could spoof browser UI or containing-page content. While the [original `` proposal](https://open-ui.org/components/popup.research.explainer-v1) did not discuss this issue, the [`` proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md#security) does have a specific section at least mentioning this issue. Some top-layer APIs (e.g. the fullscreen API) make it possible for an element to exceed the frame bounds in some cases, great care must be taken in these cases to ensure user safety. Given the complete flexibility offered by the pop-up API (any element, arbitrary content, etc.), there would be no way to ensure the safety of this feature if it were allowed to exceed frame bounds. +Allowing a popover/top-layer element to exceed the bounds of its containing frame poses a serious security risk: such an element could spoof browser UI or containing-page content. While the [original `` proposal](https://open-ui.org/components/popup.research.explainer-v1) did not discuss this issue, the [`` proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md#security) does have a specific section at least mentioning this issue. Some top-layer APIs (e.g. the fullscreen API) make it possible for an element to exceed the frame bounds in some cases, great care must be taken in these cases to ensure user safety. Given the complete flexibility offered by the popover API (any element, arbitrary content, etc.), there would be no way to ensure the safety of this feature if it were allowed to exceed frame bounds. -For completeness, several use counters were added to Chromium to measure how often this type of behavior (content exceeding the frame bounds) might be needed. These are approximations, as they merely measure the total number of times one of the built-in “pop-up” windows, which can exceed frame bounds because of their carefully-controlled content, is shown. The pop-ups included in this count include the `` color picker, and the `` date/time picker. Data can be found here: +For completeness, several use counters were added to Chromium to measure how often this type of behavior (content exceeding the frame bounds) might be needed. These are approximations, as they merely measure the total number of times one of the built-in “popover” windows, which can exceed frame bounds because of their carefully-controlled content, is shown. The popovers included in this count include the `` color picker, and the `` date/time picker. Data can be found here: -* Total pop-ups shown: [0.7% of page loads](https://chromestatus.com/metrics/feature/timeline/popularity/3298) -* Pop-ups appeared outside frame bounds: [0.08% of page loads](https://chromestatus.com/metrics/feature/timeline/popularity/3299) +* Total popovers shown: [0.7% of page loads](https://chromestatus.com/metrics/feature/timeline/popularity/3298) +* Popovers appeared outside frame bounds: [0.08% of page loads](https://chromestatus.com/metrics/feature/timeline/popularity/3299) -So about 11% of all pop-ups currently exceed their owner frame bounds. That should be considered a rough upper bound, as it is possible that some of those pop-ups **could** have fit within their frame if an attempt was made to do so, but they just happened to exceed the bounds anyway. +So about 11% of all popovers currently exceed their owner frame bounds. That should be considered a rough upper bound, as it is possible that some of those popovers **could** have fit within their frame if an attempt was made to do so, but they just happened to exceed the bounds anyway. In any case, it is important to note that this API cannot be used to render content outside the containing frame. ## Shadow DOM -Note that using the API described in this explainer, it is possible for elements contained within a shadow root to be pop-ups. For example, it is possible to construct a custom element that wraps a pop-up type UI element, such as a ``, with this DOM structure: +Note that using the API described in this explainer, it is possible for elements contained within a shadow root to be popovers. For example, it is possible to construct a custom element that wraps a popover type UI element, such as a ``, with this DOM structure: ```html - + - Pop-up text here! - + Popover text here! + ``` -In this case, the (closed) shadow root contains a `
` that has `popup=auto` and that element will be shown on the top layer when the custom element calls `div.showPopUp()`. +In this case, the (closed) shadow root contains a `
` that has `popover=auto` and that element will be shown on the top layer when the custom element calls `div.showPopover()`. This is "normal", and the only point of this section is to point out that even shadow dom children can be promoted to the top layer, in the same way that a shadow root can contain a `` that can be `showModal()`'d, or a `
` that can be `requestFullscreen()`'d. ## Eventual Single-Purpose Elements -There might come a time, sooner or later, where a new pop-up-type HTML element is desired which combines strong semantics and purpose-built behaviors. For example, a `` or `` element. Those elements could be relatively easily built via the APIs proposed in this document. For example, a `` element could be defined to have `role=alert` and `popup=manual`, and therefore re-use this pop-up API for always-on-top rendering. In other words, these new elements could be *explained* in terms of the lower-level primitives being proposed for this API. +There might come a time, sooner or later, where a new popover-type HTML element is desired which combines strong semantics and purpose-built behaviors. For example, a `` or `` element. Those elements could be relatively easily built via the APIs proposed in this document. For example, a `` element could be defined to have `role=alert` and `popover=manual`, and therefore re-use this popover API for always-on-top rendering. In other words, these new elements could be *explained* in terms of the lower-level primitives being proposed for this API. # The Choices Made in this API @@ -665,10 +665,10 @@ That document discusses the pros and cons for each alternative. After exploring Again, refer to the [Other Alternatives Considered](/components/popup.proposal.alternatives) document for an exhaustive look at the other alternatives. That document runs through a fairly complete design of the other alternatives, to see what they would look like. -This section simply tries to summarize the primary reason that a content attribute was chosen to enable the pop-up behavior: a content attribute allows *behavior* to be applied to *any element*. That is useful: +This section simply tries to summarize the primary reason that a content attribute was chosen to enable the popover behavior: a content attribute allows *behavior* to be applied to *any element*. That is useful: ```html - + This is a "light dismiss" dialog @@ -678,7 +678,7 @@ This section simply tries to summarize the primary reason that a content attribu Here, the developer is building **a dialog**. Since HTML [strongly encourages](https://html.spec.whatwg.org/multipage/dom.html#semantics-2) the use of the correct element that properly represents the **semantics of the content**, the proper element in this case is a ``. ```html - +
    • @@ -689,7 +689,7 @@ Similarly here, the developer is building **a menu**, so they should use the ``, all of the above would need to be carefully managed by the developer via ARIA roles and attributes, as there is no single role that can consistently be used to identify a `` element: +In an alternative proposal where the popover behavior is enabled via a special element, e.g. ``, all of the above would need to be carefully managed by the developer via ARIA roles and attributes, as there is no single role that can consistently be used to identify a `` element: ```html @@ -698,7 +698,7 @@ In an alternative proposal where the pop-up behavior is enabled via a special el and that violates the [first rule of ARIA](https://www.w3.org/TR/using-aria/#firstrule), which is essentially that if there's an element that properly represents the content, use that, and don't use ARIA. -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: `` and ``. In that Web, many common patterns would either be very convoluted or simply not possible. +By having `popover` 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: `` and ``. In that Web, many common patterns would either be very convoluted or simply not possible. ## Design decisions (via [OpenUI](https://open-ui.org/)) @@ -713,7 +713,7 @@ Many small (and large!) behavior questions were answered via discussions at Open - [IDL reflects only valid values](https://github.com/openui/open-ui/issues/491#issuecomment-1118927375) - [Why `togglepopup` (bikeshed)](https://github.com/openui/open-ui/issues/508) - [Why `defaultopen` (bikeshed)](https://github.com/openui/open-ui/issues/500) -- [Why `display:none` for hidden pop-ups](https://github.com/openui/open-ui/issues/492) +- [Why `display:none` for hidden popovers](https://github.com/openui/open-ui/issues/492) - [Why Close Signals and not just ESC](https://github.com/openui/open-ui/issues/320) - [Naming of the `:top-layer`/`:open` pseudo class](https://github.com/openui/open-ui/issues/470) - [Support for "boolean-like" behavior for `popup` attribute](https://github.com/openui/open-ui/issues/533) @@ -728,9 +728,13 @@ Many small (and large!) behavior questions were answered via discussions at Open - [Show and hide animation behavior](https://github.com/openui/open-ui/issues/335) - [`popuptoggletarget`, `popupshowtarget`, `popuphidetarget`](https://github.com/openui/open-ui/issues/382#issuecomment-1184773425) - [Invoking attributes only supported on buttons](https://github.com/openui/open-ui/issues/420) -- [Differences between dialog and pop-up](https://github.com/openui/open-ui/issues/581) -- [Interactions between pop-up, dialog, and fullscreen](https://github.com/openui/open-ui/issues/520) +- [Differences between dialog and popover](https://github.com/openui/open-ui/issues/581) +- [Interactions between popover, dialog, and fullscreen](https://github.com/openui/open-ui/issues/520) -Here are all non-spec-text related OpenUI pop-up issues, both open and closed: +Here are all non-spec-text related OpenUI popover issues, both open and closed: - https://github.com/openui/open-ui/issues?q=is%3Aissue+label%3Apopup+-label%3Apopup-spec + https://github.com/openui/open-ui/issues?q=is%3Aissue+label%3Apopover+-label%3Apopover-spec + +Here are all current, open, non-spec-text related OpenUI popover issues: + + https://github.com/openui/open-ui/issues?q=is%3Aissue+is%3Aopen+label%3Apopover+-label%3Apopover-spec+-label%3Apopover-v2