CSS Anchoring API 👋

[jh3y]

Hey 👋

Wanted to start by saying great work with both popper and floating-ui 👏 I read a statistic that popper is used in almost 4% of websites!

From #1804 you're likely aware there is a CSS Anchoring API in the works that got recently promoted to "Editors Draft" in the specs: drafts.csswg.org/css-anchor-1/. I think the fact this spec exists is likely a great testament to the work you've been doing.

We were wondering if you had any thoughts on the spec? Or what do you think would be really important to be included in the spec? Could a CSS interface be useful for popper and floating-ui?

Your insight would be great as someone who's pretty close to the subject. The API is currently available to experiment with in Chrome Canary behind the "Experimental Web Platform Features" flag and I've got a few demos I'd be happy to share if you're interested.

Keep up the great work!

@jh3y ʕ •ᴥ•ʔ

[FezVrasta]

Hi, thanks for the nice words, we are happy you like what we built.

We did review the CSS anchor spec internally and identified some aspects that would make it less than ideal to replace parts, or the entirety, of what Floating UI exposes today.

It's been a few months since I reviewed it the last time so maybe it evolved to address them, but some thoughts in random order are:

1. The spec doesn't mention a system to specify a custom bounding box, most of our users rely on this behavior to define where the tooltip should live;
2. It seems to use layout instead of visual viewport, this would make it difficult to, for example, display a combobox on iOS, as when the keyboard is open it will obscure the element;
3. The API feels very verbose, it takes around 20 lines of CSS rules to define a "flip" behavior, something that through Floating UI is achieved with a single flip() middleware;
4. It doesn't seem to provide a system to detect if the element is partially or completely hidden/clipped;
5. I couldn't find any example that addresses arrow positioning;
6. There doesn't seem to be any JavaScript interface to interact with it;

We are happy to talk more about it if you'd like to, even directly on Meet.

[jh3y]

Hey! 👋

Thank you so much for the valuable insights and feedback on the current state of the API. It's really great feedback 🙏
We are taking a little time to review it and explore how and where the API can cater.

Thank you also for the offer to meet with us!

[atomiks]

@jh3y I have some questions about the current state of the CSS anchoring API. Ideally, the positioning part of the library could leverage most of the native CSS API (with fallback for older browsers), and sort of pivot to being more of a wrapper around the positioning logic?

How much of the current middleware functionality can be replicated with only CSS?

• Is there an equivalent to shift, where it keeps the same "placement"/side but merely shifts itself to stay in view?
• What is the current state of being able to position arrows? Can they read which current @try block is used? If shift() is possible, can an arrow know the "shifted" amount such that it can appear centered to the anchor element?
• Is it possible to anchor an element to one that's inside an iframe? We got a fair number of issues about that last year until I fixed it - I don't think it's common but it seems to have a use case.
• Is size()'s availableHeight and availableWidth possible?
• autoPlacement likely isn't possible since @position-fallback works like flip(), though this isn't really a major deal since flip() is much more common/useful.
• It looks like hide() is possible? In Chrome Canary the floating element hides itself when it's out of view at the bottom (although not at the top?).

Others:

• Is it possible to provide a JavaScript API equivalent for virtual elements, e.g. for following the cursor or positioning a context menu without needing to inject a fake anchor node into the DOM to do so?

[tabatkins]

Sorry for the delay in this comment.

Is there an equivalent to shift, where it keeps the same "placement"/side but merely shifts itself to stay in view?

Not currently. This was discussed in w3c/csswg-drafts#7757, but it's a chunk of additional complexity to figure out exactly how it would work and how to specify it. (Flipping, on the other hand, is pretty trivial.) If this is important, opening an issue in CSSWG with details on how y'all do it would be great!

What is the current state of being able to position arrows? Can they read which current @Try block is used? If shift() is possible, can an arrow know the "shifted" amount such that it can appear centered to the anchor element?

Currently it's not possible to know what position set you're in, but the plan is to add an @container query that'll let you select on this.

This approach obviously wouldn't let you pipe in the "shift" amount; that would have to be done somewhat differently (and is part of the complexity of the "shift" ability).

Is it possible to anchor an element to one that's inside an iframe? We got a fair number of issues about that last year until I fixed it - I don't think it's common but it seems to have a use case.

Ooof, not easily. As far as CSS is concerned, the insides of an iframe are completely invisible to the outer page; the iframe is just an opaque rectangle, no different from an img.

In theory we could do something about this, but it would be pretty novel. I'm not sure if the layout of iframe contents is tied to the rendering timing of the outer page (it's certainly undefined by CSS, but HTML may or may not say something about it); if not, this is even more troublesome.

Is size()'s availableHeight and availableWidth possible?

It's not in the current spec, but that information is available. Could you describe some use-cases for it (preferably in a CSSWG issue)?

autoPlacement likely isn't possible since @position-fallback works like flip(), though this isn't really a major deal since flip() is much more common/useful.

Right, not currently available. In theory it's doable - it would rely on the same sort of information that the fallback/overflow calculation does - but it wasn't brought up as a use-case early. If there are use-cases, we can def pursue it in the future, tho.

It looks like hide() is possible? In Chrome Canary the floating element hides itself when it's out of view at the bottom (although not at the top?).

This actually isn't possible currently, but it's something I believe definitely needs to be done as part of the initial implementation. I haven't written it up yet because there are some details that weren't certain, but it sounds like y'all have made these decisions already, presumably with good reasons. ^_^

If I'm reading this correctly, y'all's implementation lets you choose between hiding when (a) the positioned element is fully outside of the anchor's containing block (or nearest scrollport?), or (b) the anchor is fully scrolled out of its nearest scroller, or (c) both. Plus a margin changing the size of the positioned element or anchor, as appropriate.

Is this right? Do y'all find both of these important? Is there anything else you wish you would or could do in this space?

Is it possible to provide a JavaScript API equivalent for virtual elements, e.g. for following the cursor or positioning a context menu without needing to inject a fake anchor node into the DOM to do so?

We don't have one yet, but have an open issue for matching the pointer, at least: w3c/csswg-drafts#8639. Absolutely possible, there's nothing weird about the timing here. Do y'all have use-cases for stuff beyond the pointer?

(Hm, I suppose the "position relative to an element inside an iframe" is a reasonable use-case.)

[tabatkins]

The spec doesn't mention a system to specify a custom bounding box, most of our users rely on this behavior to define where the tooltip should live;

I opened an issue that I think addresses this a few days ago w3c/csswg-drafts#8724, letting you select an element to use for your overflow calculations (rather than using the positioned element's CB). Would this work?

It seems to use layout instead of visual viewport, this would make it difficult to, for example, display a combobox on iOS, as when the keyboard is open it will obscure the element;

Hm, this comes out of the fact that it just uses the CB of the positioned element, and that's based on the layout viewport (for fixpos and top-layer stuff). But opting a fixpos into the visual viewport is something we've thought about at least some; @bramus would have a little more info about that, probably.

Worst case, the API I mention above for selecting your containment box could be extended to allow this; the syntax would allow it no problem.

The API feels very verbose, it takes around 20 lines of CSS rules to define a "flip" behavior, something that through Floating UI is achieved with a single flip() middleware;

This is fixed now; specifying position: absolute; top: anchor(--foo auto); automatically aligns your top with with the bottom of your anchor, and auto-flips if necessary. (Or bottom: anchor(--foo auto); for the reverse; same with left/right.)

It doesn't seem to provide a system to detect if the element is partially or completely hidden/clipped;
I couldn't find any example that addresses arrow positioning;
There doesn't seem to be any JavaScript interface to interact with it;

I believe I addressed all of these in my preceding response. Please let me know if there are any details I missed responding to!

[bramus]

(#) But opting a fixpos into the visual viewport is something we've thought about at least some; @bramus would have a little more info about that, probably.

There’s been some discussion going on in w3c/csswg-drafts#7475 about this, where a new type of viewport has been suggested: the “PosFixedViewport” aka “Unzoomed Visual Viewport”. It has the size of the Visual Viewport, but its size is not affected by pinch-zoom – similar to how the Layout Viewport’s size is not affected by pinch-zoom.

In the visual below (from this interactive demo), you can see the Layout Viewport (blue), Visual Viewport (red), and the Unzoomed Visual Viewport (green):

The linked-to issue is leaning towards introducing this new type of viewport, but it still undecided on making it the default or doing it via an opt-in (which I am leaning to)

However, should that new type of viewport land, it doesn’t cover scenarios where the anchor is not position: fixed and just happens to be visually just somewhere between the virtual keyboard and the top window edge because the document’s scroll position puts it there.

Preferably – and I think this is what the OP is suggesting – when trying to position the anchored element, the logic should try and take the presence of the virtual keyboard (or any other interactive widget for that matter) into account.

This would play nice not only with full-width virtual keyboards, but also with split-keyboards – You wouldn’t want the anchored element to be rendered underneath any of those interactive widgets or parts thereof.

I can see how this would complicate things implementation-wise, though.

[xiaochengh]

The spec has evolved quite a bit after these months. Adding to the previous answers:

@FezVrasta

The spec doesn't mention a system to specify a custom bounding box, most of our users rely on this behavior to define where the tooltip should live;

We've decided to add a new property for this purpose: w3c/csswg-drafts#8724

It should get into the spec soon.

@atomiks

How much of the current middleware functionality can be replicated with only CSS?

• offset: just a calc like top: calc(anchor(bottom) + 10px)
• shift: no direct support yet, but it's still doable by making the target element position:sticky inside an anchor-positioned container. See demo https://jsfiddle.net/3xytvL5h/
• flip: anchor(auto)
• arrow: we'll introduce a CQ for it in the future, as previously answered. This one should be doable, but is technically very complicated in terms of both spec and implementation (because there's style depending on layout), so we don't expect it to land soon
• size: this one is probably the only one fundamentally not doable, because it requries a layout recalc on every scroll change, which makes scrolling janky and is something we explicitly try to avoid; the current @position-fallback requires relayout only when switching to a different fallback position, though
• autoPlacement: not currently supported, but should be doable if the following spec issues can be resolved
  • Specify a custom bounding box for position fallback (see [css-anchor-position-1] Using a specific box (not your CB) to determine position-fallback w3c/csswg-drafts#8724, will be added to spec soon)
  • Preserve the previously used fallback position when all fallback positions fail (see [css-anchor-1] Preserve the previously used fallback position when all fallbacks fail w3c/csswg-drafts#8200, proposed)
• hide: we are introducing a new property for the same purpose, though not exactly in the same way. See [css-anchor-1] Need ability to say "don't render" when anchor is off-screen w3c/csswg-drafts#7758 (comment)
• inline: we currently don't support this. When the anchor element is fragmented (due to inline or multicol layout), the current spec only allows us to choose "axis-aligned bounding rectangle of the fragments' border boxes". But maybe we can augment the anchor() function with an additional parameter so that we can anchor to a specific fragment? I filed [css-anchor-1] Allow anchoring to a particular fragment w3c/csswg-drafts#8895

[atomiks]

@xiaochengh thanks!

I can see some great progress has been made, but these are two really important ones I'm currently confused about:

shift

This isn't just for sticky behavior, it's mainly for preventing collision without changing the placement. For example, the following demo fails when it's near the edge of the viewport:

If it overflows on the inline axis of the placement (alignment), does the @try fallback logic also kick in? Or does the collision detection only work on the block axis (i.e. axis running along the side)?

If it works on the inline axis, one workaround would be to fallback to bottom-start / bottom-end when it overflows, and not be fully dynamic like shift(). However, on narrower screens, if it's wide enough, and depending on the anchor location, it can still overflow the screen due to its size, without it. So it's not completely robust.

Centering

How do you center the floating element relative to its anchor without knowing its width and not using translate: -50% (since that can cause blurring on low PPI displays, and then collision detection won't work since it's based on layout)? It seems like it can only have a fixed size / you have to knows its size to do this?

[xiaochengh]

Regarding shift:

If it overflows on the inline axis of the placement (alignment), does the @try fallback logic also kick in?

Yes.

Looks like shift is a frequently demanded feature, so I'm thinking if we should add first-class support for it. I'll need to do more research.

---

Regarding centering:

This can be done properly with justify-content: center, though not one line of CSS. See this example in the spec: https://drafts4.csswg.org/css-anchor-position-1/#example-fcdb8337

And if the browser doesn't support abs(x), it can be replaced by max(x, -x).

[xiaochengh]

Update regarding shift:

We explored more use cases with the technique of anchor-positioned container + sticky-positioned content (as in the demo), and think like it should be strong enough, and should be the right way to go.

However, there's still substantial spec work to do to figure out the interaction between anchor-scroll and sticky positioning. Please follow the progress at w3c/csswg-drafts#8448

[AndrewKGuan]

Hi Floating-UI experts,
with the information about the Popover API mentioned above, do you think it's enough browser-level support to swap into the library? Or is it still very tangled to carve out parts of the feature set to take advantage of the API?

[atomiks]

I mean the @floating-ui/react library is the only library that provides interactions where the popover API can be used. Referring to:

make sense to switch part of the library's underlying implementations to use the API

The vanilla library (@floating-ui/dom) is just the JS "polyfill" for the CSS anchor positioning feature.

[AndrewKGuan]

Ah I see, that makes sense.
Please keep me posted.

[atomiks]

Ok, I'll give it a go maybe this weekend! I'm assuming there are feature detection checks you can use if the browser supports it? "popovertarget" in HTMLElement or such (edit: HTMLElement.prototype.hasOwnProperty("popover"))? Will try to report back with any limitations I find.

[AndrewKGuan]

Thanks again! For feature detection, it can be done by checking for the presence of the JS interface methods: https://developer.mozilla.org/en-US/docs/Web/API/Popover_API#instance_methods
For example, something likeif(HTMLElement.hidePopover) {use the API}

And the "standard" way, if there is such a thing, is HTMLElement.prototype.hasOwnProperty('popover')
https://open-ui.org/components/popover.research.explainer/#idl-attribute-and-feature-detection

[AndrewKGuan]

Hi there, how was the test with the the popover API going? Thanks!