- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 13:49:23 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <alisonmaher> fantasai: we have some behaviors that change if using anchor pos<br> <alisonmaher> ...which containng block use when attached to scrollable element<br> <alisonmaher> ...whole scrollable area or initial cont block<br> <alisonmaher> ...also new alignment keyword<br> <alisonmaher> TabAtkins: that's all for now<br> <alisonmaher> fantasai: for these there are 2 diff directions<br> <alisonmaher> ...1 is only care about position area prop<br> <alisonmaher> ...the other is care about either pos area or anchor functions<br> <alisonmaher> TabAtkins: also anchor pos set to non initial vls<br> <alisonmaher> iank_: agree<br> <alisonmaher> ...that encapsulates pos area<br> <alisonmaher> fantasai: not quite<br> <alisonmaher> iank_: you can detect if you have invalid anchor..?<br> <alisonmaher> ...to resolve anchor func need to know if valid<br> <alisonmaher> ...so can key off of that<br> <alisonmaher> TabAtkins: has to be from non initial value<br> <alisonmaher> iank_: ??<br> <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<br> <alisonmaher> fantasai: initial is auto<br> <fantasai> The position-anchor property initial value is 'auto', which looks up implicit anchors<br> <TabAtkins> re-adding the "implicit" keyword to position-anchor, to explicitly indicate your'e using the implicit ancchor<br> <fantasai> so you can have a default anchor without having set anything<br> <alisonmaher> fantasai: we can't key off of initial val<br> <alisonmaher> TabAtkins: should be able to<br> <alisonmaher> ...same as saying pos area top left. Indicating intent<br> <alisonmaher> fantasai: yes but...yeah<br> <alisonmaher> ...you have pos anchor property. You can have it set to auto and can be anchor pos<br> <alisonmaher> fantasai: <whiteboarding><br> <alisonmaher> ...using anchor pos is one option any of these, or any subset<br> <alisonmaher> ...anchor functions dont show up in comp value<br> <alisonmaher> ..I wonder if we can say pos anchor and pos area trigger it<br> <alisonmaher> ...or just pos area<br> <alisonmaher> iank_: just keying of pos area creates delta. It changes to using scrollable cont block<br> <alisonmaher> ...I want to avoid that<br> <alisonmaher> fantasai: when using anchor function you do run into the same issue<br> <alisonmaher> iank_: exactly<br> <alisonmaher> TabAtkins: just limit to pos anchor and pos area<br> <alisonmaher> ...just want to set anchor pos anyways, and you get scrolling behavior<br> <alisonmaher> fantasai: right but you are not going to set anchor pos to non-none<br> <TabAtkins> TabAtkins: you can, if we re-add the 'implicit' keyword<br> <alisonmaher> TabAtkins: don't understand why opposed to implicit keyword<br> <alisonmaher> fantasai: small set of people who are going to know how to do it that way<br> <alisonmaher> TabAtkins: another reason to add it, more that are added, mult things, authors will want to be able to choose<br> <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<br> <alisonmaher> TabAtkins: you are imposing this now<br> <alisonmaher> fantasai: more obvious to key off of all 4 if possible<br> <alisonmaher> kizu: when they apply<br> <alisonmaher> TabAtkins: none of the behavior changes matter unless abspos<br> <alisonmaher> kizu: if we define this and want to use it somewhere else for some reason<br> <alisonmaher> fantasai: alt we need to track if we have a default anchor<br> <alisonmaher> ...can key off of that, even if implicit<br> <alisonmaher> TabAtkins: can't do that because of popover, breaks popover. They have implicit anchor but don't use it<br> <alisonmaher> ...that's intentional<br> <alisonmaher> ...the presence of imp anchor can't be the key<br> <alisonmaher> fantasai: maybe key off of pos area and the functions<br> <alisonmaher> ntim: agree<br> <alisonmaher> TabAtkins: that's fine<br> <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?<br> <alisonmaher> iank_: warry of all anchor functs. Prefer anchor areas and non-initial<br> <alisonmaher> fantasai: that won't work with popover<br> <alisonmaher> TabAtkins: we already have 2 sources of imp anchors. We could add two keywords: popover and pseudo<br> <alisonmaher> ...we have to do it at some point<br> <alisonmaher> fantasai: don't want magic<br> <alisonmaher> ...nobody will use that property to get magic behavior<br> <alisonmaher> ...initial val of anchor is auto. Sometimes gives you an anchor and sometimes not<br> <alisonmaher> iank_: popover is fixedpos by default. Doesn't matter<br> <alisonmaher> TabAtkins: that's correct<br> <alisonmaher> iank_: fixedpos isn't going to use scrollable cont block. Won't matter<br> <alisonmaher> ...pos area and non-initial pos anchor works<br> <alisonmaher> ...for limited case of scrollable cont block. Other cases might be diff in future<br> <alisonmaher> TabAtkins: the dialog keyword depends on using anchor pos<br> <alisonmaher> ...so having auto to trigger that, then its broken. You need to be using it<br> <alisonmaher> ...which is unfortunate if you want to use funcitons and cant trigger<br> <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<br> <alisonmaher> iank_: single insets ignore alignment?<br> <alisonmaher> TabAtkins: what?<br> <alisonmaher> iank_: only when using pos area<br> <alisonmaher> TabAtkins: that switch is keyed to pos area. That's why we wanted to switch to this key<br> <alisonmaher> fantasai: can prob get away with keying off of pos area<br> <alisonmaher> ...if not using pos area, you aren't depending on alignment anymore<br> <alisonmaher> TabAtkins: I suppose<br> <alisonmaher> ...if you have a popover that pos with top and left anchor function, assuming dialog keyword gives you right sizing behavior...<br> <alisonmaher> fantasai: auto gives fit content sizing, that's what it does<br> <alisonmaher> ...key off of pos anchor<br> <alisonmaher> TabAtkins: more concerned about the other one working with manual insets<br> <alisonmaher> fantasai: scrollable imcb ?? don't need to worry about compat<br> <alisonmaher> ...is someone likely using popover with anchor pos?<br> <alisonmaher> TabAtkins: prob not, use fixedpos instead<br> <alisonmaher> fantasai: might be able to key off of anchor pos property, no do I have an anchor<br> <alisonmaher> ...or key off of pos area and anchor functions<br> <alisonmaher> TabAtkins: don't like diff signals if we can avoid it<br> <alisonmaher> fantasai: don't mind too much<br> <alisonmaher> ....what would authors expect for scrollable cont block<br> <alisonmaher> ...all of these are weird<br> <alisonmaher> ...it can create weird cases<br> <alisonmaher> TabAtkins: if you use anchor you intent to use anchor pos. Ok with fallback getting that behavior<br> <alisonmaher> iank_: I prefer simple, key off non-initial instead<br> <alisonmaher> fantasai: can't be non initial<br> <alisonmaher> ...Needs to be if you have default anchor<br> <alisonmaher> ...need to check are initial value or did you find anchor<br> <alisonmaher> ...or third do we have a default anchor or do we have non initial default anchor<br> <alisonmaher> ...not sure which<br> <alisonmaher> TabAtkins: can do 2 default anchor things<br> <TabAtkins> if the property is non-auto *or* you have an implicit anchor<br> <alisonmaher> iank_: may specify but not define it<br> <alisonmaher> ....we do key off of if we find default anchor elsewhere so would lean on that more by default<br> <alisonmaher> fantasai: ok<br> <alisonmaher> iank_: can revisit<br> <alisonmaher> fantasai: scrollable case is if you found a default anchor<br> <alisonmaher> TabAtkins: make our attachment auto go one way or the other<br> <alisonmaher> fantasai: dialogs don't have a default anchor<br> <alisonmaher> TabAtkins: no<br> <alisonmaher> ...Mason is fine with breaking issues in popover if it allows us to do better things<br> <alisonmaher> PROPOSED: the dialog alignment keys off of pos area if it is the initial value<br> <alisonmaher> RESOLVED: the dialog alignment keys off of pos area if it is the initial value<br> <alisonmaher> PROPOSED: the pos attachment to scrollable area keys off of whether you found default anchor<br> <alisonmaher> ntim: what does default anchor mean<br> <alisonmaher> TabAtkins: if we find valid anchor, other things care, this would be one more<br> <alisonmaher> ntim: that's the only one<br> <alisonmaher> fantasai: yes<br> <alisonmaher> RESOLVED: the pos attachment to scrollable area keys off of whether you found default anchor<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12552#issuecomment-3210696721 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 13:49:24 UTC