[csswg-drafts] [css-anchor-position] Various bits of feedback (#12466)

jakearchibald has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position] Various bits of feedback ==
Sorry for putting all this in one issue. I'm happy to split things out, but it isn't currently clear to me what's my misunderstanding vs browser bugs vs spec issues. Anyway here goes:

## I table-flipped on `position-area`

I tried using `position-area: top` on a popover, but it 'didn't work' until I figured out I also needed to set `margin: 0`. But even with that, the popover was still overflowing the viewport in trivial cases. I felt there was too much magic and restrictions with `position-area`, so I gave up, and went to the lower level features instead.

I think [the `margin: 0` issue is tracked here](https://github.com/w3c/csswg-drafts/issues/10258), although it doesn't mention `margin` specifically. I think the viewport-overflowing issue is down to incorrect implementations.

### Should it overflow the viewport by default?

[Here's a simple demo](https://codepen.io/jaffathecake/pen/ogjvaJe?editors=1100), where the popover overflows the viewport in both Chrome and Safari, but [the spec](https://drafts.csswg.org/css-anchor-position-1/#position-area-alignment) says:

> If all three tracks are selected, the default alignment in that axis is [anchor-center](https://drafts.csswg.org/css-anchor-position-1/#valdef-justify-self-anchor-center).

And [that spec](https://drafts.csswg.org/css-anchor-position-1/#anchor-center) says:

> The new anchor-center value makes this case extremely simple: if the positioned box has a [default anchor box](https://drafts.csswg.org/css-anchor-position-1/#default-anchor-box), then it is centered (insofar as possible) over the default anchor box in the relevant axis.

A note goes on to clarify that it shouldn't overflow the viewport, although I don't see that said in normative text, unless the "insofar as possible" is doing all the heavy lifting?

I'm 90% sure both Chrome and Safari are getting this wrong, but since both are doing the same thing, I wanted to check. Additionally, [in a WebKit bug I filed](https://bugs.webkit.org/show_bug.cgi?id=295322#c4), folks are claiming the overflowing behaviour is 'expected'.

## `safe` and `anchor-center`

In Chrome:

- `justify-self: anchor-center` - avoids overflowing the viewport
- `justify-self: safe anchor-center` - overflows the viewport
- `justify-self: unsafe anchor-center` - overflows the viewport

In Safari:

- `justify-self: anchor-center` - overflows the viewport
- `justify-self: safe anchor-center` - overflows the viewport
- `justify-self: unsafe anchor-center` - overflows the viewport

Neither of these combinations make sense to me, but I couldn't find anything in the spec to say how these values should interact. It feels like the behaviour should either be:

- `justify-self: anchor-center` - avoids overflowing the viewport
- `justify-self: safe anchor-center` - avoids overflowing the viewport
- `justify-self: unsafe anchor-center` - overflows the viewport

Or:

- `justify-self: anchor-center` - overflows the viewport
- `justify-self: safe anchor-center` - avoids overflowing the viewport
- `justify-self: unsafe anchor-center` - overflows the viewport

…depending on what the default is when safe/unsafe isn't specified. It feels like the second option is more consistent with other uses of `justify-self`, but I don't have strong feelings.

## Implicit anchor elements & pseudo elements

In [this demo](https://codepen.io/jaffathecake/pen/ogjvaJe?editors=1100), I `all: unset` on the popover, and instead give the popover's `::before` and `::after` `position-area: top` and `bottom` respectively. Chrome & Safari disagree on the position of the popover, and both its pseudo elements.

It seems like, in Chrome, the [implicit anchor element](https://drafts.csswg.org/css-anchor-position-1/#implicit-anchor-element) also applies to pseudo elements. Whereas in Safari, it does not. My gut feeling is that Safari is correct here. Although, it would be nice to have something like `position-anchor: inherit-implicit` that I could use on inner elements (including pseudos) to pick up the parent implicit anchor element.

I ran into this issue [in my 'footnote' popover implementation](https://jakearchibald.com/2025/give-footnotes-the-boot/#update-are-my-alternatives-too-disruptive:~:text=it%2C%20scanning%20for%20the%20next%20closing-,parenthesis%20is%20pretty%20easy,-8) (click the superscript 8), because I want to `all: unset` the popover, and instead position an inner element, and an `::after`, to independently position the 'bubble' and the arrow. I forgot to set `position-anchor` on the pseudo, which didn't matter in Chrome, but broke in Safari. But to be clear, I think Safari is right.

---

If any of this needs further discussion than just "file a bug with [browser(s)]" or "no you misunderstood", I'll split them off into other issues.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12466 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 9 July 2025 10:03:27 UTC