[css-anchor-1] Allow anchoring to a particular fragment

[xiaochengh]

When an element is fragmented across lines/columns, the current spec says we can only anchor to the axis-aligned bounding box of its fragments. But sometimes we want to anchor to the first/last fragment instead.

For some real world use cases, if we have selected a few lines of text:

• When we press the context menu button, the context menu is anchored to the first fragment
• On touch devices, the selection handles are anchored to the first and last fragments

Floating UI supports this: https://floating-ui.com/docs/inline

How about adding an additional parameter to anchor() and anchor-size() to specify which fragment to anchor to? For example:

anchor(--foo first left)
anchor(--bar last right)
anchor(--baz bounding-box top)

And the default value is bounding-box

[kizu]

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).

[fantasai]

Agenda+ to ask if we should add this functionality in some form (and then we can follow up with specifics).

[bernhardf-ro]

Another case this would be very useful for is paged media. Addressing fragments would likely be much easier for document authors to understand and use than the bounding boxes of all fragments. (We are not even sure ourselves what the bounding box of fragments spread over multiple pages should be, especially when these pages vary in size. But that feels like it's own issue.)

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-1] Allow anchoring to a particular fragment, and agreed to the following:

• RESOLVED: add margin-box and border-box keywords
• RESOLVED: add properties position-anchor-name and position-anchor-box as longhands of position-anchor

The full IRC log of that discussion

<emeyer> TabAtkins: It was raised that there's several possible boxes of an anchor that could be anchored to
<emeyer> …Spec says the axis-aligned bounding box of fragments
<emeyer> …This is reasonable most of the time, but there are probably cases where we want to anchor to other boxes, like the margin box
<emeyer> …There's plenty of space in the syntax to declare which box or fragment you want to anchor to
<emeyer> …There are some proposed values like first and last; I might want first-fragment and last-fragment to be more clear
<fantasai> +1 to longer keyword for first/last fragment
<astearns> q+
<emeyer> …We would still default to the current behavior
<iank_> q+
<emeyer> …Does this sound like something reasonable to pursue?
<emeyer> astearns: Box keywords, absolutely; not so convinced about fragments
<astearns> ack astearns
<emeyer> TabAtkins: If something's split across a column-break, you probably want to pick one of the two fragments at some point
<kizu> q+
<una> q+
<astearns> ack iank_
<emeyer> iank_: Just making sure this is grounded in use cases
<emeyer> TabAtkins: Are any of the boxes a problem?
<astearns> ack iank_
<khush> q+
<emeyer> iank_: Inner boxes like content and padding, but implementations tend to ignore the existence of scrollbars
<emeyer> …In CSS shapes, browser get the padding box wrong when there's a scrollbar
<emeyer> …Fine to have these values, but just want to make sure people are asking for them first
<emeyer> TabAtkins: Border and margin are the most obvious to have, and I don't like subsetting, but I'm okay with it to the extent that values are working well
<emeyer> iank_: Generally, padding-box and content-box of everything is broken with respect to scrollbars
<astearns> ack fantasai
<emeyer> fantasai: I think a major use case for fragments is sometimes people want to put a doohickey at the beginning or end of an inline that can wrap to multiple lines
<emeyer> …I expect this would be used a lot when does against inline boxes
<emeyer> …Tab's CSS Day demo showed these box values would be valuable
<emeyer> …Content and padding are not as useful for a lot of use cases, but you could use them to place things on top of an anchor, like a "New" banner in the corner of some content
<astearns> ack kizu
<emeyer> kizu: With wrapping inline elements, JS tooltips have this problem as well
<astearns> ack una
<emeyer> …Wrapping through columns is the same case, but would we want to attach to whole column fragments?
<emeyer> una: I think anchors are confusing to authors
<emeyer> s/anchors/fragments/
<emeyer> TabAtkins: I don't think we've really exposed fragments to authors; let's open an issue about terminology, or continue in this one
<astearns> ack khush
<emeyer> khush: When we did view transitions, this came up there as well
<khush> https://github.com/w3c/csswg-drafts/issues/8339#issuecomment-1470268830
<emeyer> …It would be nice if we had a generic syntax to deal with other cases of fragments
<emeyer> …I vaguely recall us talking about being able to put this in selectors
<emeyer> iank_: No no no
<emeyer> TabAtkins: Good to know
<emeyer> fantasai: Back to margin/border box keywords, we also need to be able to specify this for the default anchor
<emeyer> …IN our exploration last July, position-anchor was a shorthand that let you include name and box
<emeyer> …Not sure what to do with the fragments case
<astearns> q?
<emeyer> …What do authors call it when a thing splits across lines?
<astearns> ack fantasai
<Zakim> fantasai, you wanted to point out for margin-box etc need to add it to default anchor
<iank_> itsy-bitsy-splitsy-box
<fantasai> https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-positioning
<emeyer> TabAtkins: I suggest we resolve to add margin-box and border-box keywords to anchor functions and position-anchor, and I'll open an issue about padding-box and content-box keywords, and we resolve to do something with fragmentation but we need to figure terminology
<fantasai> position-anchor -> position-anchor-name + position-anchor-box
<emeyer> astearns: A general fragmentation thing would be useful, but in this case, do we only want to have access to the first and last fragments?
<emeyer> fantasai: Yes
<emeyer> TabAtkins: Yes
<emeyer> astearns: Any objections to the first resolution?
<emeyer> (silence)
<emeyer> RESOLVED: add margin-box and border-box keywords
<emeyer> fantasai: We need to also resolve to add these to anchor-position property
<dbaron> s/keywords/keywords to anchor functions/
<astearns> s/anchor-position/position-anchor/
<emeyer> …We probably want to split those into longhands position-anchor-name and position-anchor-box
<emeyer> …Any objections to adding those?
<emeyer> (silence)
<emeyer> RESOLVED: add properties position-anchor-name and position-anchor-box as longhands of position-anchor
<RRSAgent> I have made the request to generate https://www.w3.org/2024/06/11-css-minutes.html fantasai
<fantasai> s/ARIA is the right approach/asking authors to use ARIA markup directly is the right approach/