# Popover
_Box Kite 2.1.0 · a markdown copy of https://www.box-kite.dev/popover/_
A panel anchored to its trigger, on the platform's own Popover API: the top layer, light dismiss and focus return are the browser's, so there is no portal and no z-index to manage.
**Import**
```jsx
import Popover from '@box-kite/react/components/popover';
```
**Usage**
```jsx
}>
```
## There is no portal
A popover is in the browser's **top layer**: it paints above every stacking context and outside every clipped ancestor, which is the entire class of bug a portal exists to work around. Measured in Chrome 152 against a sibling with `z-index: 9999`, a `transform`ed ancestor and an `overflow: hidden` one — the panel wins all three, and `position: fixed` loses two of them.
Because nothing is moved, the panel keeps everything it inherits where it was declared: the theme around it, the custom properties, the text direction, and its place in the tab order — trigger, then panel, then the rest of the page. A portalled layer has none of that by default, which is why `Overlay` has to carry its direction across by hand.
```jsx
// Inside a clipped, transformed, z-indexed box — and it still escapes all three.
}>
Painted above the page, clipped by nothing.
```
Clipped by nothing.
## The panel is always rendered
Closed means `display: none` from the browser's own stylesheet, not unmounted. That is what lets the browser own showing and hiding — and it is what makes the exit a plain CSS transition instead of a ``, since nothing ever leaves the DOM to be held back. The entrance is `startingStyle` and the exit is one prop, `transitionBehavior="allow-discrete"`, both already in the component's styles.
The cost is that the children render whether or not anyone has opened it. For a panel that is expensive to build, gate it yourself:
```jsx
const [open, setOpen] = useState(false);
}>
{open ? The expensive part : null}
```
## Controlled, and why a close cannot be refused
Leave `open` out and the popover owns its state. Pass it and you own it — with one asymmetry that comes from the platform: the browser's `beforetoggle` event is cancelable when it opens and **not** when it closes. So a controlled popover can refuse to open, but a light dismiss has already happened by the time you hear about it. Keep `open` true and the component shows it again rather than arguing.
```jsx
console.log(open, reason)}
trigger={(t) => }
>
```
Press Escape, or click away.
Last reason: `—`
## Focus, and the two things the platform does not do
Opening moves focus into the panel
The Popover API moves focus nowhere unless something inside carries `autofocus`. APG's dialog wants focus in the panel, so the component puts it there — on the panel itself, which is focusable by script and never by Tab. An `autofocus` inside still wins, and `autoFocus={false}` turns the whole thing off.
Closing returns focus — unless React got there first
The platform returns focus to the trigger when a popover is _hidden_, and does nothing at all when the element is _removed_ while open — focus falls to ``, which is the commonest keyboard bug in a popup. A consumer closing a controlled popover removes it, so `useFocusReturn` covers exactly that gap.
Nothing is trapped
This is a non-modal dialog: Tab leaves the panel for the rest of the page, and because the panel was never moved, "the rest of the page" is what follows the trigger. A modal that holds focus is `