[css-anchor-position] What does "using anchor positioning" mean?

[tabatkins]

We have at least one spot in the spec, currently, where behavior differs based on whether an element is "using anchor positioning" or not (and which isn't directly about anchors) - an element "using anchor positioning" uses the "scrolling containing block" rather than the "local containing block" when a scroll container generates its CB. We are thinking about adding more, like in #10258.

"Using anchor positioning" is currently handwaved as "has a non-none value for position-area". This is definitely a sufficient signal for the use of anchor positioning, but it's not a necessary one - an author can use anchor positioning (or at least indicate their interest in anchor positioning) in other ways:

• set position-anchor to a non-initial value (but they might be using anchor positioning with the default value)
• use an anchor() function in their inset properties
• use an anchor-size() function in several of their sizing properties

Talking with @bfgeek, we think we should add at least some of these additional signals to the concept (and actually dfn the term while we're at it). Which should we add?

1. I think a non-initial position-anchor is a gimme. Especially if we do re-add implicit as a keyword to be explicit about it (or be more specific about the implicit source, like adding popover or pseudo or something).
2. I guess use of an anchor function in inset/sizing properties is okay, it's just.... weird. You can "use" anchor functions in ways that don't actually get "used", like variable fallback, and it's unclear how we might want that to trigger. But it's kinda weird if we have behavior designed to make anchorpos work better and it doesn't trigger when you're literally using top: anchor().

[bfgeek]

For the "scrolling containing block" I think we should use if you have a valid https://drafts.csswg.org/css-anchor-position-1/#default-anchor-element (even if it is implicit)

E.g. if you have a default anchor element you'll be shifted with it upon scroll, so you should get the special "scrolling containing block" as well.

The primary reason why this matters is currently there is a pretty large behaviour difference between:

.anchored1 {
  position-anchor: --a;
  position-area: bottom;
}
.anchored2 {
  position-anchor: --a;
  top: anchor(bottom);
}

which IMO is a mistake.

The "scrolling containing block" matters most when you are applying the scroll transform IMO.

(and then provide a switch for opting into the "scrolling containing block" if you really need to for other usecases).

[css-meeting-bot]

The Houdini Task Force just discussed [css-anchor-position] What does "using anchor positioning" mean?, and agreed to the following:

• RESOLVED: the dialog alignment keys off of pos area if it is the initial value
• RESOLVED: the pos attachment to scrollable area keys off of whether you found default anchor

The full IRC log of that discussion

<alisonmaher> fantasai: we have some behaviors that change if using anchor pos
<alisonmaher> ...which containng block use when attached to scrollable element
<alisonmaher> ...whole scrollable area or initial cont block
<alisonmaher> ...also new alignment keyword
<alisonmaher> TabAtkins: that's all for now
<alisonmaher> fantasai: for these there are 2 diff directions
<alisonmaher> ...1 is only care about position area prop
<alisonmaher> ...the other is care about either pos area or anchor functions
<alisonmaher> TabAtkins: also anchor pos set to non initial vls
<alisonmaher> iank_: agree
<alisonmaher> ...that encapsulates pos area
<alisonmaher> fantasai: not quite
<alisonmaher> iank_: you can detect if you have invalid anchor..?
<alisonmaher> ...to resolve anchor func need to know if valid
<alisonmaher> ...so can key off of that
<alisonmaher> TabAtkins: has to be from non initial value
<alisonmaher> iank_: ??
<alisonmaher> TabAtkins: it's not. Need to care about popovers but may not be using anchor pos for that. Should not be treated as this by default
<alisonmaher> fantasai: initial is auto
<fantasai> The position-anchor property initial value is 'auto', which looks up implicit anchors
<TabAtkins> re-adding the "implicit" keyword to position-anchor, to explicitly indicate your'e using the implicit ancchor
<fantasai> so you can have a default anchor without having set anything
<alisonmaher> fantasai: we can't key off of initial val
<alisonmaher> TabAtkins: should be able to
<alisonmaher> ...same as saying pos area top left. Indicating intent
<alisonmaher> fantasai: yes but...yeah
<alisonmaher> ...you have pos anchor property. You can have it set to auto and can be anchor pos
<alisonmaher> fantasai: <whiteboarding>
<alisonmaher> ...using anchor pos is one option any of these, or any subset
<alisonmaher> ...anchor functions dont show up in comp value
<alisonmaher> ..I wonder if we can say pos anchor and pos area trigger it
<alisonmaher> ...or just pos area
<alisonmaher> iank_: just keying of pos area creates delta. It changes to using scrollable cont block
<alisonmaher> ...I want to avoid that
<alisonmaher> fantasai: when using anchor function you do run into the same issue
<alisonmaher> iank_: exactly
<alisonmaher> TabAtkins: just limit to pos anchor and pos area
<alisonmaher> ...just want to set anchor pos anyways, and you get scrolling behavior
<alisonmaher> fantasai: right but you are not going to set anchor pos to non-none
<TabAtkins> TabAtkins: you can, if we re-add the 'implicit' keyword
<alisonmaher> TabAtkins: don't understand why opposed to implicit keyword
<alisonmaher> fantasai: small set of people who are going to know how to do it that way
<alisonmaher> TabAtkins: another reason to add it, more that are added, mult things, authors will want to be able to choose
<alisonmaher> fantasai: no one is going to want to do this to change how anchoring to the correct element, should not be about magic side effects
<alisonmaher> TabAtkins: you are imposing this now
<alisonmaher> fantasai: more obvious to key off of all 4 if possible
<alisonmaher> kizu: when they apply
<alisonmaher> TabAtkins: none of the behavior changes matter unless abspos
<alisonmaher> kizu: if we define this and want to use it somewhere else for some reason
<alisonmaher> fantasai: alt we need to track if we have a default anchor
<alisonmaher> ...can key off of that, even if implicit
<alisonmaher> TabAtkins: can't do that because of popover, breaks popover. They have implicit anchor but don't use it
<alisonmaher> ...that's intentional
<alisonmaher> ...the presence of imp anchor can't be the key
<alisonmaher> fantasai: maybe key off of pos area and the functions
<alisonmaher> ntim: agree
<alisonmaher> TabAtkins: that's fine
<alisonmaher> fantasai: if you have non inintial and anchor and fallbacks, the last doen't use anchor pos, do you still want the switches to apply?
<alisonmaher> iank_: warry of all anchor functs. Prefer anchor areas and non-initial
<alisonmaher> fantasai: that won't work with popover
<alisonmaher> TabAtkins: we already have 2 sources of imp anchors. We could add two keywords: popover and pseudo
<alisonmaher> ...we have to do it at some point
<alisonmaher> fantasai: don't want magic
<alisonmaher> ...nobody will use that property to get magic behavior
<alisonmaher> ...initial val of anchor is auto. Sometimes gives you an anchor and sometimes not
<alisonmaher> iank_: popover is fixedpos by default. Doesn't matter
<alisonmaher> TabAtkins: that's correct
<alisonmaher> iank_: fixedpos isn't going to use scrollable cont block. Won't matter
<alisonmaher> ...pos area and non-initial pos anchor works
<alisonmaher> ...for limited case of scrollable cont block. Other cases might be diff in future
<alisonmaher> TabAtkins: the dialog keyword depends on using anchor pos
<alisonmaher> ...so having auto to trigger that, then its broken. You need to be using it
<alisonmaher> ...which is unfortunate if you want to use funcitons and cant trigger
<alisonmaher> fantasai: if youre using anchor function to do anchor pos, youre other inset is auto. Because of this not going to pay attention to alignment at all
<alisonmaher> iank_: single insets ignore alignment?
<alisonmaher> TabAtkins: what?
<alisonmaher> iank_: only when using pos area
<alisonmaher> TabAtkins: that switch is keyed to pos area. That's why we wanted to switch to this key
<alisonmaher> fantasai: can prob get away with keying off of pos area
<alisonmaher> ...if not using pos area, you aren't depending on alignment anymore
<alisonmaher> TabAtkins: I suppose
<alisonmaher> ...if you have a popover that pos with top and left anchor function, assuming dialog keyword gives you right sizing behavior...
<alisonmaher> fantasai: auto gives fit content sizing, that's what it does
<alisonmaher> ...key off of pos anchor
<alisonmaher> TabAtkins: more concerned about the other one working with manual insets
<alisonmaher> fantasai: scrollable imcb ?? don't need to worry about compat
<alisonmaher> ...is someone likely using popover with anchor pos?
<alisonmaher> TabAtkins: prob not, use fixedpos instead
<alisonmaher> fantasai: might be able to key off of anchor pos property, no do I have an anchor
<alisonmaher> ...or key off of pos area and anchor functions
<alisonmaher> TabAtkins: don't like diff signals if we can avoid it
<alisonmaher> fantasai: don't mind too much
<alisonmaher> ....what would authors expect for scrollable cont block
<alisonmaher> ...all of these are weird
<alisonmaher> ...it can create weird cases
<alisonmaher> TabAtkins: if you use anchor you intent to use anchor pos. Ok with fallback getting that behavior
<alisonmaher> iank_: I prefer simple, key off non-initial instead
<alisonmaher> fantasai: can't be non initial
<alisonmaher> ...Needs to be if you have default anchor
<alisonmaher> ...need to check are initial value or did you find anchor
<alisonmaher> ...or third do we have a default anchor or do we have non initial default anchor
<alisonmaher> ...not sure which
<alisonmaher> TabAtkins: can do 2 default anchor things
<TabAtkins> if the property is non-auto *or* you have an implicit anchor
<alisonmaher> iank_: may specify but not define it
<alisonmaher> ....we do key off of if we find default anchor elsewhere so would lean on that more by default
<alisonmaher> fantasai: ok
<alisonmaher> iank_: can revisit
<alisonmaher> fantasai: scrollable case is if you found a default anchor
<alisonmaher> TabAtkins: make our attachment auto go one way or the other
<alisonmaher> fantasai: dialogs don't have a default anchor
<alisonmaher> TabAtkins: no
<alisonmaher> ...Mason is fine with breaking issues in popover if it allows us to do better things
<alisonmaher> PROPOSED: the dialog alignment keys off of pos area if it is the initial value
<alisonmaher> RESOLVED: the dialog alignment keys off of pos area if it is the initial value
<alisonmaher> PROPOSED: the pos attachment to scrollable area keys off of whether you found default anchor
<alisonmaher> ntim: what does default anchor mean
<alisonmaher> TabAtkins: if we find valid anchor, other things care, this would be one more
<alisonmaher> ntim: that's the only one
<alisonmaher> fantasai: yes
<alisonmaher> RESOLVED: the pos attachment to scrollable area keys off of whether you found default anchor