[css-anchor-position] Various bits of feedback

[jakearchibald]

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, 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, where the popover overflows the viewport in both Chrome and Safari, but the spec says:

If all three tracks are selected, the default alignment in that axis is anchor-center.

And that spec says:

The new anchor-center value makes this case extremely simple: if the positioned box has a 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, 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, 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, pseudo elements get the implicit anchor element from their parent element. Whereas in Safari, they do 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'm not sure what the correct position of the popover should be in this case, other than noting that Chrome & Safari disagree.

I ran into this issue in my 'footnote' popover implementation (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, it's just a compat risk if things appear to 'work' in Chrome due to bugs.

---

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.

[emilio]

cc @anttijk @nt1m @mfreed7

[jamesnw]

It seems like, in Chrome, pseudo elements get the implicit anchor element from their parent element. Whereas in Safari, they do 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.

Pseudo elements should have an implicit anchor, per #11792.

[jamesnw]

On the question of safe vs unsafe-

In Chromium, the inline axis seems to be implemented with unsafe, for instance justify-self: unsafe anchor-center. This means that content can overflow the containing block on both sides. It confusing also means that explicitly adding justify-self: anchor-center differs from the implicit justify-self: anchor-center specified as it opts into the "neither safe nor unsafe" behavior that shifts the content into the containing block on both sides.

Here's a demo showing just the inline behavior- https://codepen.io/jamessw/pen/YPyKLZP?editors=1100

When we look at both axes, it gets even more unclear- https://codepen.io/jamessw/pen/EajBPPY.

In Chromium, the block axis seems to be "neither safe nor unsafe".

In Safari, this is reversed — the inline axis is "neither safe nor unsafe" and the block axis is unsafe.

Because this differs in an unexpected way between implementations, I think it should be explicitly defined in the spec.

I think that the implicit safety should be explicitly "neither safe nor unsafe", so that content is shifted to stay inside the containing block by default on both sides, and so it matches the behavior of specifying a keyword without safe or unsafe. People can still opt into unsafe when they do want it to overflow the containing block.

[jakearchibald]

Pseudo elements should have an implicit anchor, per #11792.

Yes but unless I'm misunderstanding that issue, that doesn't explain the behaviour in Chrome. It's the wrong element. As in, the implicit anchor is defined to be the host of the pseudo element, whereas in Chrome it seems to be the implicit anchor of the host.

Edit: Ohh, now I look at the commit, it seems like Chrome has the old behaviour. That needs to change quickly before it becomes a compat issue.

[nt1m]

cc @fantasai @tuankiet65

[bfgeek]

In Chromium, the block axis seems to be "neither safe nor unsafe".

This is defined in:
https://drafts.csswg.org/css-align-3/#auto-safety-position

And was recently changed in:
3e31514
#12020

(Blink doesn't yet implement this new behaviour but for the example above it doesn't matter).

For position-area: left will result in align-self: anchor-center justify-self: end.

The intent for the default overflow is to "shift" within containing-block such that it doesn't overflow. This is what Blink is doing in the block-axis.

WebKit is incorrect in the block-axis AFAICT.

In the inline-axis per the updated specification, WebKit is correct, but IMO this is an undesirable behaviour, as its trivial to overlap the anchor (which is bad IMO).

In Safari, this is reversed — the inline axis is "neither safe nor unsafe" and the block axis is unsafe.

Its safe in the inline-axis. Its applying:

Otherwise, start-align the alignment subject within the overflow limit rect (similar to safe).

IMO the default for any non-anchor-center should be unsafe for that reason. cc/ @tabatkins

[bfgeek]

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

"safe" is defined to fallback to "start" alignment if it overflows - and in combination with fixedpos will result in unreachable content.

[jakearchibald]

So "safe" is unsafe by design?

[jamesnw]

So "safe" is unsafe by design?

My understanding is that on the end-side, safe and unsafe are identical. Only the unspecified neither shifts content on the end-side. (EDIT: This might be the portion that is changing? If that's the case, all 3 options seem to be identical on the end-side?)

its trivial to overlap the anchor (which is bad IMO).

"safe" is defined to fallback to "start" alignment if it overflows - and in combination with fixedpos will result in unreachable content.

I agree that both of these cases are bad. The question is which is worse, and the answer is it depends on the situation and the design of the anchor, and whether the positioned element's containing block is the viewport or clips the overflow. We could try to define more heuristics here, on whether the positioned element is clipped, or maybe try shifting in one axis at a time to see if it solves overflow without overlapping the anchor, but I'm not sure if that's possible or preferable.

My preference is that the implicit safety in the case of position-area should be the same as the default in general (neither safe nor unsafe). I'm not sure that we can say the usage of position-area is significantly different than other use cases of overflowing aligned absolutely positioned blocks.

I do think users are most likely to reach for position-try to handle these situations, but opting in to unsafe or safe behavior would also be useful.

[tabatkins]

Right, we had to balance different types of badness here. When the CB is relatively small, with space around it, the specified default behavior (which shifts the positioned element to keep it within the CB) looks bad - it can cause overlap with the anchor while appearing to avoid using the plentiful space surrounding it. But when the CB is the size of the screen, the specified default behavior is exactly what you want - it avoids the positioned element going off-screen (either into the unscrollable area, or making the page pop a horizontal scrollbar). Similarly if the CB is small but a scroller.

We judged that fixpos and top-layer anchor-pos (and abspos that doesn't have a containing block, so it hits the root), where the CB is the width of the screen, was going to be a very common case, and the failure mode of unsafe was somewhat worse in this case, so we biased towards safety here (shifting to keep it in the CB).

[jakearchibald]

I might be being dim, but I'm still not sure what the intended behaviour is when anchor-center is mixed with safe, unsafe, vs neither.

[fantasai]

@jakearchibald For anchor-center:

• unsafe means center wrt the anchor absolutely, even if it overflows
• safe means center wrt the anchor unless this overflows the inset-modified containing block (i.e. the area you get when you set place-content: stretch), in which case start-align... the goal of the keyword is to make sure there's no clipping (hence "safe") though I guess in the case of anchor positioning, it's got its own problems (potentially overlapping the anchor).
• neither means center wrt the anchor to the extent possible without overflowing the IMCB. If it's too big to fit within the IMCB, then overflow in the direction that keeps the alignment as close as possible to the ideal anchor-center alignment while avoiding overflowing the containing block in any direction; but do not ever overflow the start edge of the containing block.

Btw, I updated WebKit to match the spec more closely last week and submitted some WPTs for it (though now that I'm reviewing this issue, WebKit might still be slightly off in some overflowing cases).

I think my conclusions reading your comments here are that

• We really need to figure out some way to fix this popover default situation.
• The spec needs more pictures, better cross-linking, etc.

[jakearchibald]

@fantasai those behaviours for safe and unsafe (and neither) make sense to me.

We really need to figure out some way to fix this popover default situation.

Agreed.

The spec needs more pictures, better cross-linking, etc.

I think it's fine aside from struggling to see the default behaviour for anchor-center. It's there in a note, but I couldn't see it outside of the note.