Popover anchor positioning: the `anchor()` example needs `position-anchor: auto`

### MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Popover_API/Using

### What specific section or headline is this issue about?

Popover anchor positioning

### What information was incorrect, unhelpful, or incomplete?

Three related problems in this one section.

**1. The prose is broader than the actual behavior.**

> Because the association between the popover and the invoker is implicit, an explicit association does not need to be made using the [`anchor-name`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/anchor-name) and [`position-anchor`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/position-anchor) properties. However, you still need to specify the positioning CSS.

This holds when you position with `position-area`. It does not hold when you position with `anchor()`.

**2. The `anchor()` code sample in this section does not position anything.** As published:

```css
.my-popover {
margin: 0;
inset: auto;
bottom: calc(anchor(top) + 20px);
justify-self: anchor-center;
}
```

The initial value of `position-anchor` is `normal`, which behaves as `none` while `position-area` is `none`. So there is no default anchor element, `anchor(top)` is not a resolvable anchor function, and the `bottom` declaration becomes invalid at computed-value time. `justify-self: anchor-center` does not compensate, because its effect is conditional on the same thing.

The adjacent `position-area: top` sample is unaffected and still works. `position-area` is exactly what makes `normal` behave as `auto`.

**3. The demo this section links to is broken.** The note points at the [popover hint demo](https://mdn.github.io/dom-examples/popover-api/popover-hint/) as evidence that no explicit association is needed. Its `index.css` uses the same pattern with no `position-anchor`, so the popovers are no longer positioned relative to their invokers. The fallback placement differs by engine. Chrome renders them at the top-left of the viewport, Firefox and Safari Technology Preview render them near the invoker but unanchored, overlapping the button.

Tested against that demo, reading `position-anchor` on `#tooltip-1`:

| Browser | computed `position-anchor` | Demo |
| ------------------------- | -------------------------- | ----- |
| Firefox (stable) | `normal` | fails |
| Chrome 152.0.7977.65 | `normal` | fails |
| Safari Technology Preview | `normal` | fails |
| Safari 26.6.2 | `auto` | works |

To reproduce in one line, on the linked demo:

```js
getComputedStyle(document.querySelector("#tooltip-1")).getPropertyValue(
"position-anchor",
);
```

Three engines have shipped `normal` and all three fail. Safari 26.6.2 still computes `auto` — the pre-`normal` initial value — which is why it is the only one where the documented behavior still holds. There is no console warning in any of them, so this fails silently.

### What did you expect to see?

That following the section produces an anchored popover.

Suggested prose, replacing the sentence quoted above:

> Because the association between the popover and the invoker is implicit, you do not need to name the anchor using `anchor-name`. The implicit anchor is adopted automatically when you position with `position-area`. If you position using `anchor()` or `anchor-center` instead, set `position-anchor: auto` to opt in. The initial value of `position-anchor` is `normal`, which behaves as `none` while `position-area` is `none`.

Suggested code (one added declaration):

```css
.my-popover {
margin: 0;
inset: auto;
position-anchor: auto;
bottom: calc(anchor(top) + 20px);
justify-self: anchor-center;
}
```

The `position-area` sample needs no change.

### Do you have any supporting links, references, or citations?

[CSS Anchor Positioning Level 1](https://www.w3.org/TR/css-anchor-position-1/#position-anchor), W3C Working Draft, 27 March 2026:

> **Initial:** `normal`
>
> **`normal`** — If `position-area` is `none`, behaves as `none`. Otherwise, behaves as `auto`.
> **`auto`** — Uses the implicit anchor element if it exists; otherwise the box has no default anchor element.

[§4.2 `anchor-center`](https://www.w3.org/TR/css-anchor-position-1/#anchor-center), on why it does not compensate:

> If the box is not [absolutely positioned](https://www.w3.org/TR/css-position-3/#absolute-position), or does not have a [default anchor box](https://www.w3.org/TR/css-anchor-position-1/#default-anchor-box), this value behaves as [center](https://www.w3.org/TR/css-align-3/#valdef-self-position-center) and has no additional effect on how [inset properties](https://www.w3.org/TR/css-logical-1/#inset-properties) resolve.

And for an [unresolvable `anchor()`](https://drafts.csswg.org/css-anchor-position-1/#anchor-resolution):

> the [`anchor()`](https://drafts.csswg.org/css-anchor-position-1/#funcdef-anchor) function [computes](https://www.w3.org/TR/css-cascade-5/#computed-value) to its specified fallback value. If no fallback value is specified, it makes the declaration referencing it [invalid at computed-value time](https://www.w3.org/TR/css-values-5/#invalid-at-computed-value-time).

The change came from [csswg-drafts#13067](https://github.com/w3c/csswg-drafts/issues/13067).

### Do you have anything more you want to share?

_No response_