- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 21 Jan 2026 16:28:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] Back-compat of scrollable containing block for all abspos with implicit anchors`. <details><summary>The full IRC log of that discussion</summary> <ydaniv> fantasai: during F2F we talked about backwards compat, having a default anchor will cause difference in behavior<br> <ydaniv> ... with scrollable area and initial containing block<br> <ydaniv> ... it will not only cover initial box but also...<br> <ydaniv> ... as HTML introduces anchor attribute that will intefere with defaults<br> <ydaniv> ... instead introduce a new initial value none, meaning we only do the old back compat thing<br> <ydaniv> ... what that means, if you had before a popover and set up anchor in HTML, and had position-area: bottom/top it would just worl=k<br> <ydaniv> ... now you also have to set it to auto explicitly<br> <ydaniv> ... seems too much to ask of authors<br> <ydaniv> ... it would be nice if anchor-position-area would just do that<br> <iank_> q+<br> <ydaniv> ... we propose that if set to anything other than none, then you also set position-anchor to auto<br> <TabAtkins> +1, this is reasonable to me (I thumbsed it up earlier)<br> <ydaniv> ... so the initial value would not be none, but rather normal/auto and it would compute according to anchor attribute<br> <flackr> +1 sounds like that would do what i expect<br> <ydaniv> astearns: we added none in previous resolution, you suggest we keep none and we add normal?<br> <ydaniv> fantasai: we add normal as initial value<br> <astearns> ack iank_<br> <TabAtkins> iank_: please type<br> <iank_> ok<br> <ydaniv> iank_: is this resolution additive? if you have a default anchor or your position-area is not initial?<br> <ydaniv> ... important to not go back on previous resolution<br> <ydaniv> fantasai: works for me<br> <ydaniv> TabAtkins: we had none to avoid anchor positioning stuff. We're adding implicit anchors don't activate things<br> <ydaniv> fantasai: one way is to have anchor-positioning the sole value to compute from<br> <emilio> q+<br> <ydaniv> ... other thing iank_ said is to have anchor-position set to some other value, or <missed><br> <ydaniv> TabAtkins: iank_ can you restate your proposal?<br> <ydaniv> iank_: that we don't lose previous resolution entirely<br> <ydaniv> ... if you have a default anchor than ...<br> <ydaniv> TabAtkins: that is what we fixed with the new initial none value, so by default nobody got the scroll containing block<br> <ydaniv> fantasai: TabAtkins you're mixing things here<br> <ydaniv> TabAtkins: the auto value gave it default anchor<br> <dbaron> s/mixing things/mixing up default anchor and implicit anchor/<br> <ydaniv> iank_: problem is we had default auto, and you'll get the scrollable containing block<br> <ydaniv> ... and resolution was to have none by default<br> <TabAtkins> rather, it's that position-anchor is what *sets* the default anchor.<br> <ydaniv> ... so if you have a default anchor is that you get a scrollable containing block, and don't want to go back on that<br> <ydaniv> TabAtkins: when it exists then that triggers the scrollable containing block, still<br> <ydaniv> iank_: so position-anchor with new value (normal) is based on whether position-area is set<br> <ydaniv> TabAtkins: yes<br> <astearns> ack emilio<br> <ydaniv> iank_: and that triggers scrollable containing block<br> <ydaniv> TabAtkins: yes<br> <ydaniv> emilio: if the idea is to make the implicit HTML anchor easier to use, wouldn't mapping the attribute that selects it a trigger property an option?<br> <ydaniv> ... would that be cleaner?<br> <ydaniv> ... cause pseudo elements would still require you...<br> <ydaniv> TabAtkins: it's a step back. We did it so popover API works by default on center of screen, or anchored<br> <ydaniv> ... and markup would do the switch<br> <ydaniv> ... but it could be in JS<br> <ydaniv> emilio: I see, ok<br> <ydaniv> ... if have an anchor attribute and that would point to an existing anchor, that we auto map it to the popover trigger attribute<br> <ydaniv> ... that would create an implicit anchor, but not a default anchor<br> <ydaniv> astearns: but if does not exist yet...<br> <ydaniv> emilio: yes<br> <ydaniv> fantasai: all of the implicit anchors are triggered the same way, no matter how it's set up, HTML etc.<br> <ydaniv> TabAtkins: the important part is it doesn't exist yet and we can talk about it later<br> <ydaniv> astearns: sounds like we're good about this change, any other concerns about a new normal initial value?<br> <ydaniv> emilio: I think we should make it behave like <missed>?<br> <futhark> +1 to behave like<br> <emilio> s/<missed>/ instead of compute to<br> <ydaniv> emilio: making the initial value computed is already weird<br> <ydaniv> ... it also introduce dependence on other properties<br> <ydaniv> astearns: minor concern would be round trips that change behavior<br> <fantasai> depending on position-area<br> <ydaniv> ... propose resolution is that we add a new initial normal value that behaves as described in the comment<br> <ydaniv> .. objections?<br> <ydaniv> RESOVLED: add a new initial normal value that behaves as described in the comment<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13067#issuecomment-3779415289 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 January 2026 16:28:39 UTC