diff --git a/research/src/pages/popup/popup.research.explainer.mdx b/research/src/pages/popup/popup.research.explainer.mdx
index c7aafd8e2..a95872395 100644
--- a/research/src/pages/popup/popup.research.explainer.mdx
+++ b/research/src/pages/popup/popup.research.explainer.mdx
@@ -6,7 +6,7 @@ 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)
-- May 9, 2022
+- June 1, 2022
 
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@@ -83,18 +83,28 @@ This section lays out the full details of this proposal. If you'd prefer, you ca
 
 A new content attribute, **`popup`**, controls both the top layer status and the dismiss behavior. There are several allowed values for this attribute:
 
-* **`popup=popup`** - A top layer element following “Popup” dismiss behaviors (see below).
+* **`popup=auto`** - A top layer element following "Auto" dismiss behaviors (see below).
 * **`popup=hint`** - A top layer element following “Hint” dismiss behaviors (see below).
 * **`popup=async`** - A top layer element following “Async” dismiss behaviors (see below).
 
 So this markup represents popup content:
 
 ```html
-<div popup=popup>I am a popup</div>
+<div popup=auto>I am a popup</div>
 ```
 
 As written above, the `<div>` will be rendered `display:none` by the UA stylesheet, meaning it will not be shown when the page is loaded. To show the popup, 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`:
+
+```html
+<div popup=auto>I am a popup</div>
+<div popup>I am also an "auto" popup</div>
+<div popup="">So am I</div>
+```
+
+For convenience and brevity, the remainder of this explainer will use this boolean-like syntax in most cases, e.g. `<div popup>`.
+
 ## Showing and Hiding a Popup
 
 There are several ways to "show" a popup, and they are discussed in this section. When any of these methods are used to show a popup, 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 popups to exist.
@@ -105,7 +115,7 @@ A common design pattern is to have an activating element, such as a `<button>`,
 
 ```html
 <button togglepopup=foo>Toggle the popup</button>
-<div id=foo popup=popup>Popup content</div>
+<div id=foo popup>Popup content</div>
 ```
 
 When the button in this example is activated, the UA will call `.showPopup()` on the `<div id=mypopup>` element if it is currently hidden, or `hidePopup()` if it is showing. In this way, no Javascript will be necessary for this use case.
@@ -116,7 +126,7 @@ If the desire is to have a button that only shows or only hides a popup, the fol
 <button togglepopup=foo>Toggle the popup</button>
 <button showpopup=foo>This button only shows the popup</button>
 <button hidepopup=foo>This button only hides the popup</button>
-<div id=foo popup=popup>Popup content</div>
+<div id=foo popup>Popup content</div>
 ```
 
 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.
@@ -145,10 +155,10 @@ There are several conditions that will cause `showPopup()` and/or `hidePopup()`
 
 ### Page Load Trigger
 
-As mentioned above, a `<div popup=popup>` will be hidden by default. If it is desired that the popup should be shown automatically upon page load, the `defaultopen` attribute can be applied:
+As mentioned above, a `<div popup>` will be hidden by default. If it is desired that the popup should be shown automatically upon page load, the `defaultopen` attribute can be applied:
 
 ```html
-<div popup=popup defaultopen>
+<div popup defaultopen>
 ```
 
 In this case, the UA will immediately call `showPopup()` on the element, as it is parsed. If multiple such elements exist on the page, only the first such element (in DOM order) on the page will be shown.
@@ -166,17 +176,29 @@ Note also that more than one `async` popup can use `defaultopen` and all such po
 <div popup=async defaultopen>Also shown on page load</div>
 ```
 
+### CSS Pseudo Class
+
+When a popup (or any element) is in the top layer, it will match the `:top-layer` pseudo class:
+
+```javascript
+const popup = document.createElement('div');
+popup.popup = 'auto';
+popup.matches(':top-layer') === false;
+popup.showPopup();
+popup.matches(':top-layer') === true;
+```
+
 
 ### Shown vs Hidden Popups
 
-The styling for a popup is provided by roughly the following UA stylesheet rules:
+The styling for a popup is provided by **roughly** the following UA stylesheet rules:
 
 ```css
-[popup i]:not(:popup-open) {
+[popup]:not(:top-layer) {
   display: none;
 }
 
-[popup i] {
+[popup] {
   position: fixed;
 }
 ```
@@ -184,15 +206,14 @@ The styling for a popup is provided by roughly the following UA stylesheet rules
 The above rules mean that a popup, when not "shown", has `display:none` applied, and that style is removed when one of the methods above is used to show the popup. Note that the `display:none` UA stylesheet rule is **not** `!important`. In other words, developer style rules can be used to override this UA style to make a not-showing popup visible in the page. In this case, the popup will **not** be displayed in the top layer, but rather at it's ordinary `z-index` position within the document. This can be used, for example, to animate the show/hide behavior of the popup, or make popup content "return to the page" instead of becoming hidden.
 
 
-
 ## IDL Attribute and Feature Detection
 
-The `popup` content attribute will be [reflected](https://html.spec.whatwg.org/#reflect) as an IDL attribute:
+The `popup` content attribute will be [reflected](https://html.spec.whatwg.org/#reflect) as a nullable IDL attribute:
 
 ```webidl
 [Exposed=Window]
 partial interface Element {
-  attribute DOMString popup;
+  attribute DOMString? popup;
 ```
 
 This not only allows developer ease-of-use from Javascript, but also allows for a feature detection mechanism:
@@ -203,14 +224,27 @@ function supportsPopup() {
 }
 ```
 
-Further, only [valid values](#html-content-attribute) of the content attribute will be reflected to the IDL property, with invalid values being reflected as the empty string `""`. For example:
+Further, only [valid values](#html-content-attribute) of the content attribute will be reflected to the IDL property, with invalid values being reflected as the value `null`. For example:
 
 ```javascript
 const div = document.createElement('div');
 div.setAttribute('popup','hint');
 div.popup === 'hint'; // true
 div.setAttribute('popup','invalid!');
-div.popup === ''; // true
+div.popup === null; // true
+```
+
+This allows feature detection of the values, for forward compatibility:
+
+```javascript
+function supportsPopupType(type) {
+  if !Element.prototype.hasOwnProperty("popup")
+    return false; // Popup API not supported
+  // If the assignment fails, it will return null:
+  return !!(document.createElement('div').popup = type);
+}
+supportsPopupType('async') === true;
+supportsPopupType('invalid!') === false;
 ```
 
 
@@ -231,14 +265,31 @@ Neither of these events are cancellable, and both are fired asynchronously.
 
 ## Focus Management
 
-Elements that move into the top layer may require focus to be moved to that element, or a descendant element. However, not all elements in the top layer will require focus. For example, a modal `<dialog>` will have focus set to its first interactive element, if not the dialog element itself, because a modal dialog is something that requires immediate attention. On the other hand, a `<div popup=hint>` (which will more often than not represent a "tooltip") does not receive focus at all (nor is it expected to contain focusable elements). Similarly, a `<div popup=async>` should not immediately receive focus (even if it contains focusable elements) because it is meant for out-of-band communication of state, and is not meant to interrupt a user's current action. Additionally, if the top layer element **should** receive immediate focus, there is a question about **which** part of the element gets that initial focus. For example, the element itself could receive focus, or one of its focusable descendants could receive focus. To provide control over these behaviors, two attributes can be used on popups:
+Elements that move into the top layer may require focus to be moved to that element, or a descendant element. However, not all elements in the top layer will require focus. For example, a modal `<dialog>` will have focus set to its first interactive element, if not the dialog element itself, because a modal dialog is something that requires immediate attention. On the other hand, a `<div popup=hint>` (which will more often than not represent a "tooltip") does not receive focus at all (nor is it expected to contain focusable elements). Similarly, a `<div popup=async>`, which may represent a dynamic notification message (commonly referred to as a toast), or potentially a persistent chat widget, should not immediately receive focus (even if it contains focusable elements). This is because such popups are meant for out-of-band communication of state, and are not meant to interrupt a user's current action. Additionally, if the top layer element **should** receive immediate focus, there is a question about **which** part of the element gets that initial focus. For example, the element itself could receive focus, or one of its focusable descendants could receive focus.
+
+To provide control over these behaviors, the `autofocus` attribute can be used on or within popups. When present on a popup or one of its descendants, it will result in focus being moved to the popup or the specified element when the popup is rendered. Note that `autofocus` is [already a global attribute](https://html.spec.whatwg.org/multipage/interaction.html#the-autofocus-attribute), but the existing behavior applies to element focus on **page load**. This proposal extends that definition to be used within popups, and the focus behavior happens **when they are shown**. Note that adding `autofocus` to a popup descendant does **not** cause the popup to be shown on page load, and therefore it does not cause focus to be moved into the popup **on page load**, unless the `defaultopen` attribute is also used.
+
+The `autofocus` attribute allows control over the focus behavior when the popup is shown. When the popup is hidden, often the most user friendly thing to do is to return focus to the previously-focused element. The `<dialog>` element currently behaves this way. However, for popups, there are some nuances. For example, if the popup is being hidden via light dismiss, because the user clicked on another element outside the popup, the focus should **not** be returned to another element, it should go to the clicked element (if focusable, or `<body>` if not). There are a number of other such considerations. The behavior on hiding the popup is:
+
+- A popup element has a **previously focused element**, initially `null`, which is set equal to `document.activeElement` when the popup is shown, if a) the popup is a `auto` or `hint` popup, and b) if the [popup stack](#the-popup-stack) is currently empty. The **previously focused element** is set back to `null` when a popup is hidden.
 
-- `autofocus`. When present on a popup or one of its descendants, it will result in focus being moved to the specified element when the popup is rendered. Note that `autofocus` is [already a global attribute](https://html.spec.whatwg.org/multipage/interaction.html#the-autofocus-attribute), but the existing behavior applies to element focus on **page load**. This proposal extends that definition to be used within popups, and the focus behavior happens **when they are shown**. Note that adding `autofocus` to a popup descendant does **not** cause the popup to be shown on page load, and therefore it does not cause focus to be moved into the popup **on page load**, unless the `defaultopen` attribute is also used.
+- When a popup is hidden, focus is set back to the **previously focused element**, if it is non-`null`, in the following cases:
+    1. Light dismiss via [close signal](https://wicg.github.io/close-watcher/#close-signal) (e.g. Escape key pressed).
+    2. Hide popup from Javascript via `hidePopup()`.
+    3. Hide popup via a **popup-contained**\* triggering element with `hidepopup=popup_id` or `togglepopup=popup=id`. The triggering element must be popup-contained, otherwise the keyboard or mouse activation of the triggering element should have already moved focus to that element.
+    4. Hide popup because its `popup` type changes (e.g. via `mypopup.popup='something else';`).
 
-- `delegatesfocus`. When present on the popup element itself, this causes the **first focusable descendent** of the popup to be focused when the popup is shown. The purpose of this attribute is to handle the cases in which the popup content or ordering is not known prior to rendering, so that `autofocus` cannot be used effectively. (Eventually, the `delegatesfocus` attribute might be made applicable to any element, not just popups, to control focus behavior more generally.)
+ - Any other actions which hide the popup will **not** cause the focus to be changed when the popup hides. In these cases, the "normal" behavior happens for each action. Some examples include:
+    1. Click outside the popup (focus the clicked thing).
+    2. Click on a **non-popup-contained**\* triggering element to close popup (focus the triggering element). This is a special case of the point just above.
+    3. Tab-navigate (focus the next tabbable element in the document's focus order).
+    4. Hide popup because it was removed from the document (event handlers not allowed while removing elements).
+    5. Hide popup when a modal dialog or fullscreen element is shown (follow dialog/fullscreen focusing steps).
+    6. Hide popup via `showPopup()` on another popup that hides this one (follow new popup focusing steps).
 
-If both `autofocus` and `delegatesfocus` are both present on the popup element, the popup element is focused when shown.
+The intention of the above set of behaviors is to return focus to the previously focused element when that makes sense, and not do so when the user's intention is to move focus elsewhere or when it would be confusing.
 
+\* In the above, "a popup contained triggering element" means the triggering element is contained within **the popup being hidden**, not any arbitrary popup.
 
 ## Anchoring
 
@@ -253,7 +304,7 @@ A new attribute, `anchor`, can be used on a popup element to refer to the popup'
 Akin to modal `<dialog>` and fullscreen elements, popups allow access to a `::backdrop` pseudo element, which is a full-screen element placed directly behind the popup in the top layer. This allows the developer to do things like blur out the background when a popup is showing:
 
 ```html
-<div popup=popup>I'm a popup</div>
+<div popup>I'm a popup</div>
 <style>
 [popup]::backdrop {
   backdrop-filter: blur(3px);
@@ -288,13 +339,13 @@ The term "light dismiss" for a popup is used to describe the user "moving on" to
 
 ### Nested Popups
 
-For at least `popup=popup`, it is possible to have "nested" popups. I.e. two popups that are allowed to both be open at the same time, due to their relationship with each other. A simple example where this would be desired is a popup menu that contains sub-menus: it should be possible to keep the main menu showing while the sub-menu is shown.
+For at least `popup=auto`, it is possible to have "nested" popups. I.e. two popups that are allowed to both be open at the same time, due to their relationship with each other. A simple example where this would be desired is a popup menu that contains sub-menus: it is commonly expected to support this pattern, and keep the main menu showing while the sub-menu is shown.
 
 Popup nesting is not posslbe/applicable to the other popup types, such as `popup=hint` and `popup=async`.
 
 ### The Popup Stack
 
-The `Document` contains a "stack of open popups", which is initially empty. When a `popup=popup` element is shown, that popup is pushed onto the top of the stack, and when a `popup=popup` element is hidden, it is popped from the top of the stack.
+The `Document` contains a "stack of open popups", which is initially empty. When a `popup=auto` element is shown, that popup is pushed onto the top of the stack, and when a `popup=auto` element is hidden, it is popped from the top of the stack.
 
 ### Nearest Open Ancestral Popup
 
@@ -314,26 +365,11 @@ The "close signal" [proposal](https://wicg.github.io/close-watcher/#close-signal
 
 
 
-The fact that only valid values are reflected allows feature detection of the values, for forward compatibility:
-
-```javascript
-function supportsAsyncPopups() {
-  if !Element.prototype.hasOwnProperty("popup")
-    return false;
-  const div = document.createElement('div');
-  div.setAttribute('popup','async');
-  return div.popup === 'async';
-}
-```
-
-
-
-
 ## Classes of Top Layer UI
 
 As described in this section, the three popup types (`popup`, `hint`, and `async`) each have slightly different interactions with each other. For example, `popup`s hide other `hint`s, but the reverse is not true. Additionally, there are other (non-popup) elements that participate in the top layer. This section describes the general interactions between the various top layer element types, including the various flavors of popup:
 
-* Popup (**`popup=popup`**)
+* Popup (**`popup=auto`**)
     * When opened, force-closes other popups and hints, except for [ancestor popups](#nearest-open-ancestral-popup).
     * It would generally be expected that a popup of this type would either receive focus, or a descendant element would receive focus when invoked.
     * Dismisses on [close signal](https://wicg.github.io/close-watcher/#close-signal), click outside, or blur.
@@ -373,20 +409,17 @@ In the table, "hide" means that when the second element is shown (enters the top
 This section details the interactions between the three popup types:
 
 1. If a `popup=hint` is shown, it should hide **any** other open `popup=hint`s, including ancestral `popup=hint`s. (**"You can't nest `popup=hint`s".**)
-2. If a `popup=popup` is shown, it should hide **any** open `popup=hint`s, including if the `popup=hint` is an ancestral popup of the `popup=popup`. (**"You can't nest a popup inside a `popup=hint`".**)
-3. If you: **a)** show a `popup=popup` (call it D), then **b)** show an **ancestral** `popup=hint` of D (call it T) , then **c)** hide D, the `popup=hint` T should be hidden. (**"A `popup=hint` can be nested inside a popup."**)
-4. If you: **a)** show a `popup=popup` (call it D), then **b)** show an **non-ancestral** `popup=hint` (call it T) , then **c)** hide D, the `popup=hint` T should be left showing. (**"Non-nested `popup=hint`s can stay open when unrelated popups are hidden."**)
+2. If a `popup=auto` is shown, it should hide **any** open `popup=hint`s, including if the `popup=hint` is an ancestral popup of the `popup=auto`. (**"You can't nest a popup inside a `popup=hint`".**)
+3. If you: **a)** show a `popup=auto` (call it D), then **b)** show an **ancestral** `popup=hint` of D (call it T) , then **c)** hide D, the `popup=hint` T should be hidden. (**"A `popup=hint` can be nested inside a popup."**)
+4. If you: **a)** show a `popup=auto` (call it D), then **b)** show an **non-ancestral** `popup=hint` (call it T) , then **c)** hide D, the `popup=hint` T should be left showing. (**"Non-nested `popup=hint`s can stay open when unrelated popups are hidden."**)
 5. The `defaultopen` attribute should have no effect on `popup=hint`s. I.e. this attribute cannot be used to cause a `popup=hint` to be shown upon page load.
 6. The `defaultopen` attribute can be used on as many `popup=async`s as desired, and all of them will be shown upon page load.
-7. Only the first `popup=popup` (in DOM order) containing the `defaultopen` attribute will be shown upon page load. (This is per-explainer, and included here for completeness.)
-
-
-
+7. Only the first `popup=auto` (in DOM order) containing the `defaultopen` attribute will be shown upon page load.
 
 
 ## Accessibility / Semantics
 
-Since the `popup` content attribute can be applied to any element, and this only impacts the element's presentation (top layer vs not top layer), this addition does not have any direct semantic or accessibility impact. The element with the `popup` attribute will keep its existing semantics and AOM representation. For example, `<article popup=popup>...</article>` will continue to be exposed as an implicit `role=article`, but will be able to be displayed on top of other content. Similarly, ARIA can be used to modify accessibility mappings in [the normal way](https://w3c.github.io/html-aria/), for example `<div popup=popup role=note>...</div>`.
+Since the `popup` content attribute can be applied to any element, and this only impacts the element's presentation (top layer vs not top layer), this addition does not have any direct semantic or accessibility impact. The element with the `popup` attribute will keep its existing semantics and AOM representation. For example, `<article popup>...</article>` will continue to be exposed as an implicit `role=article`, but will be able to be displayed on top of other content. Similarly, ARIA can be used to modify accessibility mappings in [the normal way](https://w3c.github.io/html-aria/), for example `<div popup role=note>...</div>`.
 
 As mentioned in the [Declarative Triggers](#declarative-triggers) section, accessibility mappings will be automatically configured to associate the popup with its trigger element, as needed.
 
@@ -407,7 +440,7 @@ This section contains several HTML examples, showing how various UI elements mig
 
 ```html
 <button togglepopup=datepicker>Pick a date</button>
-<my-date-picker role=dialog id=datepicker popup=popup>
+<my-date-picker role=dialog id=datepicker popup>
   ...date picker implementation...
 </my-date-picker>
 
@@ -423,7 +456,7 @@ This section contains several HTML examples, showing how various UI elements mig
 <selectmenu>
   <template shadowroot=closed>
     <button togglepopup=listbox>Icon</button>
-    <div role=listbox id=listbox popup=popup>
+    <div role=listbox id=listbox popup>
       <slot></slot>
     </div>
   </template>
@@ -484,7 +517,7 @@ This section contains several HTML examples, showing how various UI elements mig
 
 ## Exceeding the Frame Bounds
 
-Allowing a popup/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 `<popup>` proposal](https://open-ui.org/components/popup.research.explainer-v1) did not discuss this issue, the [`<selectmenu>` 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 Popup 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 popup/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 `<popup>` proposal](https://open-ui.org/components/popup.research.explainer-v1) did not discuss this issue, the [`<selectmenu>` 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 popup 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 “popup” windows, which can exceed frame bounds because of their carefully-controlled content, is shown. The popups included in this count include the `<select>` popup, the `<input type=color>` color picker, and the `<input type=date/etc>` date/time picker. Data can be found here:
 
@@ -514,7 +547,7 @@ This is "normal", and the only point of this section is to point out that even s
 
 ## Eventual Single-Purpose Elements
 
-There might come a time, sooner or later, where a new popup-type HTML element is desired which combines strong semantics and purpose-built behaviors. For example, a `<tooltip>` or `<listbox>` element. Those elements could be relatively easily built via the APIs proposed in this document. For example, a `<tooltip>` element could be defined to have `role=tooltip` and `popup=hint`, and therefore re-use this Popup API for always-on-top rendering, one-at-a-time management, and light dismiss. 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 popup-type HTML element is desired which combines strong semantics and purpose-built behaviors. For example, a `<tooltip>` or `<listbox>` element. Those elements could be relatively easily built via the APIs proposed in this document. For example, a `<tooltip>` element could be defined to have `role=tooltip` and `popup=hint`, and therefore re-use this popup API for always-on-top rendering, one-at-a-time management, and light dismiss. 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
@@ -551,3 +584,7 @@ Many small (and large!) behavior questions were answered via discussions at Open
 - [Why `defaultopen` (bikeshed)](https://github.com/openui/open-ui/issues/500)
 - [Why `display:none` for hidden popups](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` 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)
+- [Returning focus to previously-focused element](https://github.com/openui/open-ui/issues/327)
+- [The `show` and `hide` events should not be cancelable](https://github.com/openui/open-ui/issues/321)