• Anchor positioning spec: https://drafts.csswg.org/css-anchor-position-1/
• Anchoring in the OpenUI popover explainer: https://open-ui.org/components/popover.research.explainer/#anchoring

We currently can use the implicit anchor element provided by the anchor attribute associated with some id. This would be mainly used for popovers (though, at least the current implementation in Chrome Canary allows this attribute and its implicit anchor on any element).

The issue is: we currently seem to only be able to use this implicit anchor on the element itself, but we don't have access to it in any other way?

What we could want is to somehow access this anchor from elements or pseudo-elements nested inside our popover (or another element with anchor on it). This can be useful when we'd want to use this element as the tooltip arrow or another connector that should span from the popover's anchor to the popover itself.

Here is an implementation of how this should work: https://codepen.io/kizu/pen/qBJQpjm?editors=1100 — using both the anchor attribute, and the explicitly set anchor-names.

(note that there is currently a bug where we have to use the anchor attribute even if we do not use the implicit anchor and override it with the anchor-default — https://bugs.chromium.org/p/chromium/issues/detail?id=1451095)

In the example above we'd want to have an element that is nested inside the popover and which spans from it to the button it is anchored with via an anchor attribute.

If we'd use an additional element, we could add the same anchor attribute, but that would mean duplicating things.

Some ideas of possible solutions:

• When we define the implicit anchor, make it somehow inherit to all the elements inside?
• Introduce a new value for the anchor-element?
• Something else?

Is there any draft for the specs for it/an idea of how it could look? If this (or those) pseudo-elements could have anchor-names, and you could have an arbitrary number of them, then I'd agree (otherwise it won't work for the general “we want to draw a selection over N arbitrary item groups”).

Done, moved to a new issue — https://github.com/w3c/csswg-drafts/issues/8905 :)

Not to confuse with https://github.com/w3c/csswg-drafts/issues/8448 where we would want to attach things to sticky elements and use their current sticky offset, but kinda the other way around:

What if when we had an element with position: sticky; we could use anchor() for its inset properties?

We can imagine that right now, when we set

position: sticky;
top: 10px;

we virtually anchoring our element to the max() of either the nearest ancestor scroll container’s scrollport + 10px, and its containing block.

In pseudo-code we could express this as if it was

position: sticky;
top: max(anchor(scrollport top) 10px, anchor(containing-block top));

Now, there are a lot of issues with the current sticky positioning, both for cases when we're limited by the containing block, and when we're limited by a stray overflow: auto that we want to ignore (these issues make us use portalled elements to the end of the body in production, as we cannot rely on position: sticky due to the possible wrappers that break it).

After playing a bit with anchor positioning, I think that it could be a very elegant way to solve this maybe?

What if when we'd use the achor() in inset properties for a sticky element we would essentially “ignore” the current way it handles the corresponding property (the fact that it uses two different wrappers to determine the offset), but would just use what we would give it?

This way we could potentially “skip” any wrappers, like when we would want to only target a specific parent with overflow: auto, and we could also “skip” any extra wrapper divs that could go over our sticky element (like inside grids, and so on).

Main issue I see is that we could actually want to target the scrollports in a lot of cases, and not just the elements, not sure what would be the best way to handle this.

But, overall, given that, in theory, we should be free to modify the offsets of the sticky elements based on other things similarly to how we can absolutely position things in a safe way, maybe we could reuse the anchors this way?

(originally posted in https://github.com/w3c/csswg-drafts/issues/2496)

Specs:

• anchor positioning
• sticky positioning

While the sticky elements by themselves can affect the anchor element's layout, I don't think changing the inset properties of a sticky element would affect anything, as it is virtually just an offset change? So there would not be any circularity? Or am I missing some cases?

Wanted at first to create a new issue, but thought that I could just comment in this one.

The content of the issue I wanted to create:

[css-anchor-1] Could anchor positioning work for defining the targets of sticky elements?

Not to confuse with https://github.com/w3c/csswg-drafts/issues/8448 where we would want to attach things to sticky elements and use their current sticky offset, but kinda the other way around:

What if when we had an element with position: sticky; we could use anchor() for its inset properties?

We can imagine that right now, when we set

position: sticky;
top: 10px;

we virtually anchoring our element to the max() of either the nearest ancestor scroll container’s scrollport + 10px, and its containing block.

In pseudo-code we could express this as if it was

position: sticky;
top: max(anchor(scrollport top) 10px, anchor(containing-block top));

Now, there are a lot of issues with the current sticky positioning, both for cases when we're limited by the containing block, and when we're limited by a stray overflow: auto that we want to ignore (these issues make us use portalled elements to the end of the body in production, as we cannot rely on position: sticky due to the possible wrappers that break it).

After playing a bit with anchor positioning, I think that it could be a very elegant way to solve this maybe?

What if when we'd use the achor() in inset properties for a sticky element we would essentially “ignore” the current way it handles the corresponding property (the fact that it uses two different wrappers to determine the offset), but would just use what we would give it?

This way we could potentially “skip” any wrappers, like when we would want to only target a specific parent with overflow: auto, and we could also “skip” any extra wrapper divs that could go over our sticky element (like inside grids, and so on).

Main issue I see is that we could actually want to target the scrollports in a lot of cases, and not just the elements, not sure what would be the best way to handle this.

But, overall, given that, in theory, we should be free to modify the offsets of the sticky elements based on other things similarly to how we can absolutely position things in a safe way, maybe we could reuse the anchors this way?

Cc @xiaochengh & @tabatkins — I wonder if there are considerations that I miss, and how complicated is current sticky positioning from the point of adding something like that.

Moving a (reworded) part of my comment regarding sticky positioning from https://github.com/w3c/csswg-drafts/issues/8584 here:

Right now, the positions for the anchors do not take into account position: sticky when something is in a stuck position.

In practice, there were cases in my experiments where I wanted to use it: the adjusted position of an element with the position: sticky for things that should be shown for the stuck element.

Use cases:

• A stuck toolbar/header with items having tooltips/dropdowns attached to buttons inside of it
• Sticky sidebars that could also have things inside that cause anchored popovers to appear.

Another, very use-case idea — placing decorative elements onto the grid gaps or over whole columns/rows when the elements inside of them have different sizes.

CodePen: https://codepen.io/kizu/pen/abRezzL

Video:

https://github.com/w3c/csswg-drafts/assets/177485/9a142791-a019-45b2-9ae2-5a6114e0ee02

In the example I had to add an anchor-name for every element, and then use max or min to select the proper side of each “row” or “column”.

When the sizes of elements inside could be different, it can be very hard to select the proper ones. And what if the grid is not static and wraps?

Having an ability to use grid areas as targets for our anchors could be really nice in this case, as we would be able to first choose a row, column or an area, and then choose its side — allowing placing things both inside the cells, and outside, on the gaps.

The latest use-case that I can remember — the sidenotes layout. Something like one of my experiments.

Here is a quick CodePen: https://codepen.io/kizu/pen/abRebRJ?editors=1100

In it, I have a grid, with some number of columns, and elements going vertically in one of them. Then, I want to be able to position things absolutely with anchors, where:

1. Horizontal position should be based on the “aside” column defined in the grid. Without an ability to target a grid column I cannot do this, so I have to place a placeholder element there with an anchor-name which substitutes for such a grid area.
2. Vertically, I want to position an element choosing between the max of either the corresponding paragraph, or previous similarly positioned element. Second part here is easy due to the recent change, but for the first part I need to explicitly set variables both on the paragraph and on the positioned element. With an ability to target specific grid areas, I could only count the paragraph and put the row index as a variable on the positioned element, as I could then place it on the corresponding place.

Here is a video of how this behaves:

https://github.com/w3c/csswg-drafts/assets/177485/f6f2f152-f6fb-431a-b725-e581fcb6663e

Another similar case could be used potentially for something like tables (with the condition that they're implemented using CSS grids instead of table layout; I'll put aside the potential accessibility issues that can bring, let's imagine all browsers would solve this eventually). Then, something like my other experiment would be possible:

https://github.com/w3c/csswg-drafts/assets/177485/ff281395-85ca-4738-987b-6541b5f0c8ee

In the video we can see that we could select different rows/column and areas of a table — if the table was implemented with a grid, and we had an ability to target an area with anchor positioning, this would be trivial. But right now in my experiment I have to explicitly add anchor-names on elements in each column and row, just so I could target them later.

If I'll remember other cases related to this, I'll add them.

This would be really nice to have! Especially if we could expand it to support something like nth or nth-last, to select a particular fragment by its index.

Could be very helpful for things like wrapped inline elements, multicol, wrapped flex elements, and maybe grids (though, thinking of grids, I did create a separate issue, as with them we could probably utilize the existent grid-area syntax in order to select the existing areas).

Read https://github.com/w3c/csswg-drafts/issues/7661 issue and noticed @tabatkins saying

Also, I think that in general everything people want to achieve with static positioning is achieved better, easier, and more reliably with anchor positioning.

My issue here would be — I don't think an anchored element, currently, has an access to the grid of an element it would be positioned into? In order to utilize the grid with anchor positioning, right now we would need to have actual elements in the grid that we could then use as the target.

But what if we could target specific grid areas?

There are other cases where we could want to “specify” in more details what exactly we're targeting when selecting an anchor, for example, I agree that we would want an ability to target a particular fragment (https://github.com/w3c/csswg-drafts/issues/8895).

What if we could introduce a new function like grid-area() that could be used for this?

anchor(--foo grid-area(content) center);
anchor(--bar grid-area(1 / span 2) start);

This way, for a particular anchor, we would first find the element that is associated with it, then would check if it is a grid, and if so, would try to find the area by the same syntax grid-area uses.

Alternative considered for a second: using the grid-area property itself when the anchor is active, but this won't really work as we could want to have multiple anchors with different grids.