[css-anchor-1] Need ability to say "don't render" when anchor is off-screen

[tabatkins]

Consider: an anchor is inside of a scroll container. The positioned element is outside of the scroll container. This is legit if you want the positioned element, when visible, to be able to project outside of the scrollable area, such as into the margin.

However, this then means that if the anchor is scrolled outside of the scrollport, the positioned element just hovers above or below the scroll container, wherever the anchor is theoretically positioned. That is almost certainly not what you want!

So we should have some way to specify that if the anchor is off-screen, the positioned element should hide itself.

Questions:

• What does "hide itself" mean? display:none? visibility:hidden? I suspect just visibility should be used, so it still has a meaningful position and can, say, be scrollIntoView()'d.
• What anchor do we care about if you use multiple anchors? I think the right answer might be if any anchor is off-screen it should trigger.
• Does this need to be controllable? This probably needs to activate by default, but are there good reasons to have an anchored element continue to show up when its anchor is off-screen?
• Maybe this only activates when there is a scroll container between the anchor and the positioned element? When the positioned element is inside the same scroll container, it'll hide itself naturally due to the scroller, and being able to show up as you scroll near the anchor (rather than suddenly popping in when the anchor comes on-screen) seems good.

[tbondwilkinson]

I think JUST add display:none could be jarring as anchors scroll in and out of the visible content.

From an Open UI perspective for popup=hint, it might be better to trigger a hide event when anchors scroll out of the visible content, rather than hiding and reshowing.

It might be hard to guess what a good default would be for this, hiding is not a bad idea.

Another thought is that maybe sometimes people will want the anchored element to be clipped by the scroll container rather than hidden?

[tabatkins]

I think JUST add display:none could be jarring as anchors scroll in and out of the visible content.

It could be, or could not be, depending! If your anchors purposely hang out outside of the scroller, tho, you've gotta do something when the anchor is out of the viewport.

From an Open UI perspective for popup=hint, it might be better to trigger a hide event when anchors scroll out of the visible content, rather than hiding and reshowing.

I haven't dug deeply enough into OpenUI - can you give me a pointer to hide event stuff?

Another thought is that maybe sometimes people will want the anchored element to be clipped by the scroll container rather than hidden?

You can achieve this by putting the positioned element in the same scroller as the anchor.

[clshortfuse]

Just saw the blog on this and was concerned about this, watching them overlayed outside the container. My custom anchor system uses IntersectionObserver:

https://github.com/clshortfuse/materialdesignweb/blob/d0e11f0f1e27e2da19d60e8f9386cf2e4e28bf9a/mixins/TooltipTriggerMixin.js#L61-L90

this is the the anchor. If the anchor is less than 50% visible, I close the tooltip. Automatic handling is neat, but I think IntersectionObserver would handle it. Now if we're saying over CSS, then that's something else...

Edit: Newer commit

[xiaochengh]

I have a proposal that's built on top of #8724, which if resolved will allow us to specify a bounding box (not just the CB in positioned layout) for position fallback.

Then we can have a new property that controls what to do when the anchored element ends up overflowing that bounding box:

position-fallback-overflow: clip | visible

clip means the anchored element should be clipped by the bounding box. visible means no such clipping.

The initial value is clip.

---

Discussion:

1. I think using the position fallback bounding box is more natural than checking whether the anchor is off screen (or off any box). And it doesn't have any issue with multiple anchors.

2. Clipping seems to provide a better/smoother UX than hiding & showing. User probably don't want to see the element suddenly disappear when something is just slightly off screen.

3. The UX can be even smoother if we have [css-anchor-1] Preserve the previously used fallback position when all fallbacks fail #8200

4. Clipping seems more friendly to the rendering pipeline than hiding/showing, because we are just introducing a clip box.

5. Agreed that it should be activated by default. But it might be just safer to also provide an opt-out. (and it also means I don't need to massively rewrite all the existing WPT)

6. I don't think it should fire any event on its own. IntersectionObserver should be good enough, at least for now.

[tabatkins]

This is an excellent argument, and a great idea. Yeah, I think being able to clip to the box that you're using for overflow bounds sounds great.

Not sure we should default to clip, tho - allowing the element to extend out of the element by default seems fine. Like, a tooltip should be able to poke out a bit. In particular, I think that the behavior if you get it wrong is better if we default to visible: if you mean to clip and forget it's probably pretty obvious in common cases (you'll have things floating in space randomly on the page), while if we default to clip and you mean to use visible that's only obvious if the element happens to get positioned near the edge so it overflow a little bit. Plus in general it better fits our "fail visible/open" policy in CSS - you should usually design defaults so that if the author doesn't think about it the content is still visible, even if it makes the page ugly.

Okay, so I'm inclined to just go ahead and edit in #8724 and this one. I'll review #8200 as well to see if I want to go ahead and pull it in, too.

[tabatkins]

Or hm, maybe we should act as 'clip' if you have a specified -fallback-bound element, and visible if you don't. So the initial value should be an 'auto'.

[xiaochengh]

I found a real use case for the visible value: https://floating-ui.com/docs/autoPlacement

We can achieve the same by:

• Using a small position-fallback-bounding-box at the center of the viewport
• Setting position-fallback-overflow: visible
• And [css-anchor-1] Preserve the previously used fallback position when all fallbacks fail #8200

[clshortfuse]

Would visible also allow replicating this?

Recording.2023-05-31.215830.mp4

[xiaochengh]

@clshortfuse

This looks like a different thing, which is closer to Floating UI's shift that tries to keep the element in the bounding box without switching position; while this issue is about what to do when it's overflowing the bounding box.

And we don't have full support for shift yet. I have a hacky demo, but it doesn't work with position: fixed, so it probably doesn't work for popovers.

[tabatkins]

Thinking about this more as I try to write it up - rather than clipping to the overflow box, would it make more sense for the default to be "clip to the bounds of every scroller between you and the specified anchor"?

In particular, if there are two scrollers between your CB and your anchor, and the innermost has the anchor in the scrollport but the outer has the entire inner scroller out of the scrollport, you still want to clip, I assume. If we rely on just the overflow box, even if you specify an additional one with anchor-overflow-bounds, it won't be able to capture both boxes.

[xiaochengh]

I feel like we may still want some consistency between here and #8724. If we use a box for overflow clipping, we would very likely also want to use the same box to trigger position fallback.

Then everything gets really complicated if we need to consider a chain of clipping boxes. Imagine if someone wants to use the intersection of the ancestor scrollers of the anchor to trigger position fallback...

I don't have a good idea towards this direction. Some thoughts are:

• Maybe we can clip with the position fallback bounding box + any ancestor clipping boxes of the PFBB?
• How to opt-out if there are many clipping boxes? All or nothing? Or is there a way to opt out just some clipping boxes?

[tabatkins]

If we use a box for overflow clipping, we would very likely also want to use the same box to trigger position fallback.

Yeah, I definitely agree. I'm talking about an additional clip - in addition (and maybe by default?) clip to the scrollers between the anchor-scroll element and them as well. Multiple values for the clipping property (which we should move to an anchor-* name rather than position-fallback-* name, probably anchor-clip).

Like, anchor-clip: none | [ fallback || scroll ]? Meaning "clip to the position-fallback-bounds elements and/or the scroll containers of the scroll-anchor element". Initial value scroll? Or maybe none, hm.

Imagine if someone wants to use the intersection of the ancestor scrollers of the anchor to trigger position fallback...

I don't think fallback with the scrollers is necessary; the intermediate scrollers don't have any particular reason to be layout-relevant to the positioned element, they're just ways to hide the anchor and thus things that the positioned element probably wants to be hidden by as well.

[xiaochengh]

anchor-clip: none | [ fallback || scroll ] SGTM

[xiaochengh]

@wangxianzhu

I'd like to get your input here. Do you think anchor-clip: scroll is implementable?

In particular, for each anchor-positioned element, we need to duplicate a bunch of clip nodes from the ancestor scrollers of the anchor.

[xiaochengh]

Discussed with @wangxianzhu offline. This should be implementable in Chromium

The solution doesn't involve duplicating any clip nodes, but we can simply make PaintPropertyTreeBuilder switch to the scroller's clip state for the target element, so there's no performance issues either.

[xiaochengh]

A slightly revised idea: anchor-clip: auto | none, where

• auto is the default value, meaning it should be clipped by all ancestor clip boxes of the default anchor¹
• none means no clipping, same as before

There's a possibility that in the future, this gets extended into anchor-clip: auto | none | fallback | <anchor-element>, meaning this element should be clipped by all ancestor clip boxes of the target element of the value, and the impl should be pretty similar. Or even extended into a multi-value syntax. But everything feels like YAGNI at least for now.

Also auto feels much easier for people to use, although it's semantically the same as scroll you suggested previously

¹ Note that we no longer have a separate anchor-scroll element due to #8675

[xiaochengh]

I'm wondering if the default value should be auto or none. Maybe none is better.

It's pretty common to have a scroller with overflow: auto, which doesn't show a clear clip boundary to users when the content doesn't overflow. However, it should still apply clipping for anchor-clip: auto, which can be quite confusing to users, and developers may actuall want the positioned element (e.g. a tooltip) to overflow such a scroller.

On the other hand, it can be less confusing when the default value is none, so that developers can opt-in when they need clipping.

[kizu]

I would say that in my experiments I, sometimes, wanted to have the auto, but mostly wanted the none (the current behavior).

Also, I imagine clipping would also work for overflow: hidden, and that could mean that clipping by default could lead to the content being not accessible if it would go beyond the overflow of such elements.

[clshortfuse]

I've coded my tooltips to be a psuedo top-layer, so they break through their anchor's boundary. For example, this is anchored to the button, but overlays above the Nav Drawer and its scrollbar on the left:

I can simulate a clip by dropping the z-index:

An example of "don't render" because the anchor is off-screen is applicable to what I call "semi-sticky" toolbars, where it scrolls aways on scroll down, but stickied on scroll up. If the keyboard is focused on a toolbar button, the tooltip is shown. But when the toolbar button is no longer more than 50%, then it meets my custom threshold of being "off-screen" and I close the tooltip.

And mid-hide when scrolling down:

The consequence of not doing this is the issue we know where a tooltip can appear when it shouldn't:

I'm using intersection observer on the anchor as well as on the tooltip itself. Because the tooltip isn't useful without what it's giving a tip for, I want it on the anchor. But there could be an instance where the tooltip gets occluded (eg: forced position) and then I want it to hide instead of reposition when partially occluded.

I'm unsure what anchor-clip means here. Is it when the anchor (eg: the button) is clipped? Or do we mean to clip the tooltip? Is my terminology wrong? Is "anchor" the button or tooltip here?

[xiaochengh]

For example:

viewport
+- scroller
|  +- anchor
+- popover

Then anchor-clip: auto makes popover additionally clipped by scroller

[tabatkins]

Yeah, it basically gives you back the clipping that you would have if your positioned element was an abspos next to the anchor. Being able to have your positioned element elsewhere in the page is a big part of what makes anchor positioning powerful.

Also, I imagine clipping would also work for overflow: hidden

Yes, overflow:hidden is a scroller so it would act identically to overflow:scroll.

[yisibl]

And we don't have full support for shift yet. I have a hacky demo, but it doesn't work with position: fixed, so it probably doesn't work for popovers.

@xiaochengh Will css-anchor consider implementing a shift effect in the future?

[xiaochengh]

@yisibl Yes, but I don't have a clear idea how it should work. Anyway, it's better to file a separate issue for it.

[tabatkins]

Ooh, yeah, that makes sense.

I don't think we should tie it to visibility in general, at least not without further discussion (there are many ways to be invisible, after all), but in the "chained anchor" case, hidden-ness should indeed propagate, I think.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-1] Need ability to say "don't render" when anchor is off-screen.

The full IRC log of that discussion

<chrishtr> TabAtkins: this is a call for review on the details of position-visibility as defined in the ED spec
<chrishtr> TabAtkins: there was a previous resolution for the feature, but some details have been filled in
<chrishtr> TabAtkins: call to please review and otherwise we'll consider the ED spec text accepted

[wangxianzhu]

Should we rename anchors-visible to anchor-visible as only the default anchor's visibility matters?