- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 13 Nov 2025 03:10:56 +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`, and agreed to the following:
* `RESOLVED: add none value to position-anchor, make it the initial value, change UA stylesheet for popover`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> fantasai: for scrollable containing blocks of a positioned block<br>
<kbabbitt> ... when you have a scroll container, there's scrollport which doesn't move with scroll<br>
<kbabbitt> ... local containing block which is ICB equivalent for the scrollport<br>
<kbabbitt> ... and there's the scrollable containing block which roughly corresponds to entire scrollable area<br>
<kbabbitt> ... abspos boxes are defined currently if their CB is generated by a scroll container, they reference the LCB<br>
<kbabbitt> ... if I position something bottom:0, in a scroll container, it will be positioned at the initial scroll position to coincide wuth bottom wedge of scroll part and scroll with container<br>
<kbabbitt> ... with anchor pos, we have these fallback concepts and other kinds of sizing where exact position of that bottom matters<br>
<TabAtkins> "fixed" -> size of scrollport, 'outside' the scroller (like fixpos). "local" -> size of scrollport, 'inside' the scroller at top (like ICB). "scrolling" -> size of scrollable content, 'inside' the scroller (this is new and anchorpos automatically uses it sometimes)<br>
<kbabbitt> ... what's outside the container can affect layout, with try fallbacks or overflow alignment<br>
<kbabbitt> ... as we add more capabilities to abspos, that edge becomes more present even in cases where you were only referencing top and left corners<br>
<kbabbitt> ... we discussed this and decided to use the scrollable containing block as the containing block for boxes that have a default anchor element<br>
<kbabbitt> ... problem with that is that even if you just use normal anchor positioning, boxes that have implicit anchor element now have default anchor element<br>
<kbabbitt> ... and have now switched into this behavior even if they don't use anchor pos<br>
<kbabbitt> ... existing page using popover for example with position bottom 0<br>
<kbabbitt> ... will change behavior from being above the fold to below the fold<br>
<kbabbitt> ... which is a compat issue<br>
<kbabbitt> ... bottom 0 still needs to mean bottom of containing block<br>
<iank_> (popover is `position:fixed` by default so also need `position: absolute` on the popover to trigger the switch)<br>
<kbabbitt> ... but for purpose of overflow management we need a bigger area<br>
<kbabbitt> ... my proposal is that if inset is auto, we resolve it to the edge of the scrollable area<br>
<TabAtkins> q+<br>
<kbabbitt> ... rather than the edge of the local containing block<br>
<kbabbitt> ... and that creates the space we need without triggering overflow<br>
<kbabbitt> ... and without changing interpretation of a fixed length<br>
<kbabbitt> s/bottom of containing block/bottom of local containing block/<br>
<astearns> ack TabAtkins<br>
<kbabbitt> TabAtkins: I am with iank_<br>
<kbabbitt> ... not liking this particular proposed resolution because it means auto no longer has as stable and obvious thing to resolve to<br>
<kbabbitt> ... difference between leaving edge as auto and wanting to adjust a little bit<br>
<kbabbitt> ... suddenly you opt into other interpretation and get a big jump you didn't expect<br>
<kbabbitt> ... back compat issue is that having any anchor at all is what we resolved to use as a switch<br>
<kbabbitt> ... some things get anchor ayutomatcially without doing anything<br>
<kbabbitt> ... just fixing that bit would solve the back compat issue without being overly problematic in the other way<br>
<kbabbitt> ... my preferrred solution is to explicitly key off non-auto default anchor<br>
<kbabbitt> ... initial value auto will use implicit anchor<br>
<kbabbitt> ... add implicit keyword which uses implicit anchor<br>
<kbabbitt> ... that way you're affirmatively using anchor pos in a similar way to non-auto<br>
<kbabbitt> ... that way we can add more implicit anchors in the future and it won't switch positioning behavior and be low impact<br>
<kbabbitt> ... other possibilities iank_ mentioned of using ? anywhere in your insets<br>
<kbabbitt> ... we rejected doing that for other reasons, don't recall the details<br>
<iank_> i'm ok with that.<br>
<kbabbitt> ... would instead propose to add implicit keyword, and key off having anchor and non-initial value for position-anchor property<br>
<astearns> ack fantasai<br>
<kbabbitt> fantasai: I have serious problems with that approach<br>
<kbabbitt> ... 2 problems<br>
<kbabbitt> ... 1 I don't think a property that controls anchor binding and changes how it matches the binding should have a big effect on layout<br>
<kbabbitt> ... we're not changing element we're binding to, just changing keyword with exact same behavior, it just has a new side effect of changing how insets are resolved<br>
<kbabbitt> ... that's really confusing<br>
<kbabbitt> ... could have a question of whether there's a binding or not but shouldn't affect layout<br>
<kbabbitt> ... 2, need this to work by default<br>
<kbabbitt> ... if author needs to opt into ?? by default, they can do so with more obvious declaration<br>
<kbabbitt> ... so I don't think that's a good plan<br>
<kbabbitt> ... re: auto and 0 don't resolve to same thing - that's fine<br>
<kbabbitt> ... if you want 10px of spacing, add a margin<br>
<kbabbitt> TabAtkins: wasn't that auto and 0 resolve to same, auto is unpredictable value now<br>
<kbabbitt> ... can't say I want to use current edge but inset a little bit<br>
<kbabbitt> fantasai: add a margin<br>
<kbabbitt> ... auto already has a lot of cases where it has an unpredictable value<br>
<kbabbitt> ... can't say I want to be static position + 10px<br>
<kbabbitt> ... this is already a feature of auto insets<br>
<kbabbitt> iank_: for the non dominant edge it's always true you can inset a bit an dit works<br>
<kbabbitt> ... I was playing around with it and it's very weird if you jump to a local when the right hand side is on the scrolling containing block<br>
<kbabbitt> ... a lot of people do use insets in this way<br>
<kbabbitt> ... I just want you in a little bit<br>
<kbabbitt> ... people will run into jump and not understand it<br>
<kbabbitt> ... very against that<br>
<kbabbitt> fantasai: then let's require people to set position-area<br>
<kbabbitt> TabAtkins: that's saying people should use a no-op property that indicates anchor pos vs the property I'm sating<br>
<kbabbitt> fantasai: difference is position-area is a layout property<br>
<kbabbitt> ... whereas position-anchor is how I connect an abspos to its anchor<br>
<kbabbitt> ... and you want to introduce synonym to initial value<br>
<kbabbitt> ... where only difference is one has a layout side effect<br>
<kbabbitt> TabAtkins: like all the other non auto values yes<br>
<kbabbitt> ... named anchor has same side effect<br>
<kbabbitt> fantasai: no<br>
<kbabbitt> TabAtkins: currently it does<br>
<kbabbitt> ... per current spec it would give you side effect<br>
<kbabbitt> ... problem is right now if you leave as auto and get explicit anchor, that triggers side effect which has back compat<br>
<astearns> q+<br>
<kbabbitt> ... so if you say implicit anchor and have that trigger<br>
<kbabbitt> ... [missed]<br>
<kbabbitt> iank_: previous resolution was to trigger this scrollable containing block behavior off the existence of default anchor<br>
<kbabbitt> ... set via position-anchor property, not if you use position-area<br>
<kbabbitt> ... spec is currently mismatched with that resolution<br>
<kbabbitt> TabAtkins: because position-area only does something when you have a default anchor<br>
<kbabbitt> ... if we care about position-area, it's a subset of having default anchor<br>
<kbabbitt> fantasai: under current resolytion if you set position-anchor to --foo and there's no --foo you don't get behavior?<br>
<kbabbitt> TabAtkins: correct<br>
<kbabbitt> ... propose that if you have a default anchor and position-anchor is not default value you opt into the behavior<br>
<kbabbitt> fantasai: you're saying I want synonym for auto, behaves just like auto, other than it has side effect on contianingh block<br>
<kbabbitt> ... even though this property has no effect on layout prior to this discussion<br>
<kbabbitt> ... and we have separate property for that<br>
<kbabbitt> TabAtkins: we already resolved that if you have position-anchor --foo and --foo exists, that triggers<br>
<kbabbitt> fantasai: I'm saying that was a bad decision<br>
<kbabbitt> ... ok with saying you need to change position-area to span-all<br>
<kbabbitt> ... or changing the way auto insets resolve<br>
<kbabbitt> ... not okay with having a property whose sole purpose is to create a binding with 2 nearly identical values where one has side effect<br>
<kbabbitt> astearns: little confused about how this new feature could have back compat issues<br>
<kbabbitt> ... because you need to set both binding and position-area to get new behavior?<br>
<astearns> ack astearns<br>
<kbabbitt> TabAtkins: resolution we had was that if you are using anchor positioning, if your CB is a scroller, you start using scrollable containing block<br>
<kbabbitt> ... that's a good behavior if you're actyally using anchor pos<br>
<kbabbitt> ... problem is behavior for "are you using anchor pos" is just "do you have a default anchor" which is given byt the position-anchor property<br>
<kbabbitt> ... if you specifgy a name and that matches something you're clearly using anchor pos<br>
<kbabbitt> ... problem that default value auto will look for implicit anchor<br>
<kbabbitt> ... and there's several sources for that<br>
<kbabbitt> fantasai: so this would change behavior of any abspos value before pseudo element<br>
<kbabbitt> TabAtkins: something using 0 will be at bottom of scroller instead of bottom of scrollers' ICB<br>
<kbabbitt> chrisl: something being accidentally opterd in?<br>
<kbabbitt> TabAtkins: correct<br>
<kbabbitt> ... fantasai's preference is to change position-area<br>
<kbabbitt> ... not super opposed but if you don't care about position-area, it's a little strange to have to turn it on and give it a no-op value just to make your anchor pos resolve<br>
<kbabbitt> fantasai: not a no-opt, opting you into new behavior<br>
<kbabbitt> TabAtkins: my thing is, thing that gives you position-anchor, add another keyword that opts you in<br>
<miriam> q+<br>
<kizu> Could it be both: either `position-area` or an explicit `position-anchor` will opt in?<br>
<kbabbitt> ... use the fact that it's non-default value as a strong signal<br>
<astearns> q+<br>
<kbabbitt> ... also effectively a no-op since it's behavior of autp<br>
<kbabbitt> ... but if you're not using position-area in other way you don't need to put that in your styles as well<br>
<iank_> i'm strongly against setting `position-area`<br>
<iank_> notbody is going to remember how to do that.<br>
<kbabbitt> ... don't feel too strongly about which way we go, find position-area a little weird, but proposed thing about auto resolutions I do object to<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to review the position-area value<br>
<kbabbitt> fantasai: my proposal is switch to using positon-area as signal<br>
<kbabbitt> ... its initial value is none<br>
<kbabbitt> ... we have a span-all value which gets you whole 9 grid<br>
<kbabbitt> ... any non-initial value would give you containign block is entire scrollable area<br>
<kbabbitt> ... to compensate for anchor functions not using position-area in general ,change interprateation of auto for insets to expand out to sctollable area<br>
<kbabbitt> ... specific value would go back to previous behavior<br>
<kbabbitt> ... would be back compatible<br>
<kbabbitt> ... otherwise you need some explicit signal<br>
<iank_> q+<br>
<kbabbitt> ... TabAtkins is proposing new keyword for position-anchor that will opt you into that behavior<br>
<kbabbitt> ... I am saying we already have explicit switch<br>
<astearns> ack miriam<br>
<kbabbitt> miriam: tend to agree with fantasai here<br>
<kbabbitt> ... what we are changing is not the anchor but the area<br>
<kbabbitt> ... so position-area is what makes sense to do that<br>
<kbabbitt> ... wonder if we can be more explicit? not just span-all<br>
<kbabbitt> ... span-all has 2 slightly different meanings, can we explicitly say what I'm doing is opting into ... whatever it's called<br>
<kbabbitt> ... does feel like we're talking about the area, that's what's changing<br>
<kbabbitt> ... if we can say it more explicitly taht's good<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to react to miriam to respond to that<br>
<kbabbitt> fantasai: earlier we discussed a proposal to differentiate between these 3 CBS<br>
<TabAtkins> (what do you mean by "2 slightly different meanings"?)<br>
<kbabbitt> ... fixed, local, scrollable containing blocks<br>
<kbabbitt> .... plan to work on switch for those 3 explicitly<br>
<kbabbitt> ... would affect 9-grid for position-area as well as everything else<br>
<kbabbitt> ... initially proposed auot to allow anchor pos to just work<br>
<kbabbitt> ... there will be an ability to explicitly do that<br>
<kbabbitt> fantasai: span-all aready says use whole 9 grid<br>
<kbabbitt> ... bounds of that is whole scrollable CB<br>
<kbabbitt> TabAtkins: was curoius what miriam meant by 2 slightly different meanings<br>
<kbabbitt> miriam: is that what fantasai just clarified?<br>
<kbabbitt> TabAtkins: yes we use entire scrollable CB<br>
<kbabbitt> miriam: if that means that already ... just noting there's a difference between different containers you could consider 9 grid to be part of or offset of, and we're switching from one to another<br>
<kbabbitt> ... in that case I agree with fantasai straightforwardly<br>
<kbabbitt> astearns: kind of sounds like we are relitigating the initial design that relied almost entirely on anchor functions and we made a decision to go with position-area instead<br>
<kbabbitt> ... perfectly happy having the anchor functions trigger on position-area as opposed to the position-anchor property<br>
<kbabbitt> ... particularyly since position-anchor has defauylt value that authors might find themselves having to work around without making any anchor pos decisions<br>
<kbabbitt> ... I am probably confused myself but i think I am weakly in favor of fantasai's proposal<br>
<kbabbitt> TabAtkins: which version?<br>
<kbabbitt> astearns: using position-area as the trigger<br>
<astearns> ack iank_<br>
<astearns> ack astearns<br>
<kbabbitt> iank_: don't really like position-area to change the behavior of the insets<br>
<fantasai> [The two variants were a) use position-area or b) use position-area and also reinterpret inset:auto ]<br>
<kbabbitt> ... you can use anchor pos in 2 different ways<br>
<kbabbitt> ... position-area or insets with anchor functions<br>
<kbabbitt> ... when you're working in anchor function mode, having to remember oh it's not working in scroll container, I need to set position-area span-all, no one's going to do that<br>
<kbabbitt> ... so I strongly dislike that<br>
<kbabbitt> ... to the point where I'll probably object on API design standpoint<br>
<TabAtkins> miriam, the 9-grid just divvies up *whatever* the CB is; span-all means "use the whole 9-grid". It doesn't *inherently* say anything about which CB you're using, but it does function as a signal for "i'm using anchor positioning", which is a signal we want to use to automatically opt you into the scrollable CB. (and we have resolution to change 'position' to let you explicitly choose your CB too, but this is just to flip the "default" answer)<br>
<kbabbitt> ... shouldn't have to care about position-area if just using anchor functions<br>
<kbabbitt> ... variant could be, if you have a non-implicit default anchor or using position-area, I'd be happy with that<br>
<kbabbitt> ... doesn't affect popover which is position:fixed<br>
<kbabbitt> ... unless you change to absolute<br>
<kbabbitt> ... will affect before, after<br>
<kbabbitt> ... but not sure of compat of that anyway<br>
<kbabbitt> ... my preferred solution is non-implicit default anchor, or use position-area property<br>
<astearns> ack fantasai<br>
<kbabbitt> fantasai: I think it's a bit weird to have the method of the binding change the layout<br>
<kbabbitt> ... whether or not there's a binding makes sense, but not method<br>
<kbabbitt> ... we want people to choose binding depending on whetehr it's presentational or semantic effect, not what layout side effects it has<br>
<kbabbitt> ... would not expect layout side effects based on choice of HTML or CSS<br>
<kbabbitt> ... would be nice if anchor pos just worked, why I proposed having auto value of insets resolve to edges of scrollable CB<br>
<TabAtkins> the issue Ian has with "rely on position-area" is that it means some otherwise-very-similar styles act wildly differently, as he pointed out in https://github.com/w3c/csswg-drafts/issues/12552#issuecomment-3141570111<br>
<kbabbitt> ... maybe not ideal that inset 10px doesn't get you 10px inset from currently effective scolling container<br>
<TabAtkins> example: .anchored1 {<br>
<TabAtkins> position-anchor: --a;<br>
<TabAtkins> position-area: bottom;<br>
<TabAtkins> }<br>
<TabAtkins> .anchored2 {<br>
<TabAtkins> position-anchor: --a;<br>
<TabAtkins> top: anchor(bottom);<br>
<TabAtkins> }<br>
<kbabbitt> ... but easy to use marcgins if you want spacing<br>
<kbabbitt> ... [missed] is not an unreasonable thing for auto to do<br>
<kbabbitt> iank_: I think it is unreasonable, most people use insets rather than margins for htis<br>
<kbabbitt> TabAtkins: pretty opposed to the auto change<br>
<fantasai> s/[missed]/having auto resolve to a non-zero value/<br>
<kbabbitt> ... don't like its magic<br>
<kbabbitt> astearns: how do we resolve this standoff?<br>
<kbabbitt> fantasai: hear from more people<br>
<kbabbitt> astearns: should we take this back to the issue and go through examples?<br>
<kbabbitt> ... iank_, you said you played with it and it was bad, would be helpful to see what you were playing with<br>
<kbabbitt> iank_: I can do that<br>
<kbabbitt> TabAtkins: example in chat, our current resoluytion which relies on default anchor, both of those get scrollable containing block<br>
<kbabbitt> ... using position-area has a little more magic but for raw positioning they work the same<br>
<kbabbitt> ... if we only use position-area as switch, these two would be dramatically different<br>
<kbabbitt> ... using anchor function would most certtainly be overflowing and trigger fallbacks<br>
<kbabbitt> ... because you'd use the LCB which is above the fold section<br>
<kbabbitt> ... which is weird because it looks like you're using anchor pos<br>
<kbabbitt> ... authors have to use no-op position-area value<br>
<flackr> q+<br>
<kbabbitt> ... onlh problme with intiial reasolution is that it has back compat in non anchor pos cases<br>
<kbabbitt> ... we ideally want to just exclude back compat problem rather than change reoslyutionmore dramatically<br>
<astearns> ack flackr ;<br>
<astearns> ack flackr<br>
<kbabbitt> flackr: do we have evidence that there is a compat issue with changing abspos behavior in this case?<br>
<kbabbitt> TabAtkins: we don't have examples in the wild, certain it exists, will hapen if anyone has done before element with abspos and bottom 0 containign block scroller<br>
<kbabbitt> flackr: what's the use case for that?<br>
<kbabbitt> TabAtkins: if you have ever used anything with bottom inset in CB scroller you will have changed behavior<br>
<kbabbitt> ... what we did in past will change position<br>
<kbabbitt> flackr: sizing changes would be bigger issue<br>
<kbabbitt> TabAtkins: yes for example top0 bottom: 0<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to comment on the example with implicit anchors<br>
<kbabbitt> ... suddenly you're size of entire scroller<br>
<kbabbitt> fantasai: back to TabAtkins example he's using position-anchor to connect<br>
<kbabbitt> ... if you rely on position-anchor that would not exist<br>
<kbabbitt> ... that's the case that's creating some of the tension here<br>
<kbabbitt> ... an anchor exists but not using position-anchor property<br>
<astearns> s/on position-anchor/on the implicit position-anchor/<br>
<kbabbitt> ... would be nice if that just worked<br>
<kbabbitt> ... but what TabAtkins is proposing is that top example would be just position-area bottom since we have ancghor<br>
<kbabbitt> ... but second example would have to say position-anchor something as well as anchor top anchor bottom<br>
<kbabbitt> ... would be nice to make that just work, fact ytou have to say position-anchor in order to get your containing block to work is quite weird<br>
<kbabbitt> ... shouldn't change layout behavior<br>
<fantasai> ... you already have an anchor association, and you're not associating it<br>
<kbabbitt> TabAtkins: though your proposal ignoring inset ayuto for a bit would still require another line there<br>
<kbabbitt> ... which is just as much ofa put a no-op in<br>
<kbabbitt> fantasai: right, that's why I wanted to change interpretation of autop<br>
<kbabbitt> ... and if you add an extra line, it should be position-area<br>
<fantasai> (and not position-anchor)<br>
<kbabbitt> TabAtkins: we'll object to changing auto inset behavior in the way that was suggested<br>
<kbabbitt> ... however what if we go with a non-implicit anchor or a non-none position area<br>
<kbabbitt> ... that way in the example from iank_ either position-anchor --a or position-area span-all would work<br>
<kbabbitt> fantasai: don't think it is good for authors to have implicit anchor have different behaviors than explicit anchor<br>
<kbabbitt> ... don't think method of binding should have effect on layout<br>
<miriam> q+<br>
<kbabbitt> ... if all keywords have special side effect except initial that makes a little more sense<br>
<kbabbitt> ... don't want to push authors to consider layout effects when trying to decide if they should use explicit or implicit binding, HTML or CSS<br>
<iank_> q+<br>
<kbabbitt> ... that shouldn't be about whether there's a layout effect, only about what is appropriate type of binding<br>
<kbabbitt> .... also thing it's weird to use binding property as layout switch<br>
<kbabbitt> ... less objectionable if it's not deciding which binding to use, but using a binding property as a binding switch is still weird and I think confusing<br>
<astearns> ack miriam<br>
<fantasai> s/binding switch/layout switch/<br>
<kbabbitt> miriam: seems like all this is caused by making everything magical without opting in<br>
<kbabbitt> ... wonder about just having a literal opt-in<br>
<kbabbitt> ... default of position-anchor is not auto, it's none<br>
<kbabbitt> ... and you have to set to auto if you want an anchor<br>
<TabAtkins> q for fantasai: wait, are you okay with "non-initial position-anchor *or* position-area", so using the implicit anchor with position-area switches? because that's totally fine with me<br>
<kbabbitt> ... or explicitly opt into anchor pos for anything else to work<br>
<kbabbitt> ... would be a normal thing in CSS<br>
<kbabbitt> ... for positon-anchor, real opt-in<br>
<astearns> ack iank_<br>
<kbabbitt> iank_: what was the reason that we didn't want to trigger off anchor functions on insets?<br>
<kbabbitt> TabAtkins: don't remember and that's a problem<br>
<kbabbitt> ... we resolved to not do it early in the proposal discussion, year + ago<br>
<kbabbitt> ... don't recall exactly what the issue was<br>
<kbabbitt> emilio: don't remember either<br>
<kbabbitt> TabAtkins: we decided not to do that, don't remember exact reason<br>
<kbabbitt> emilio: anchor functions ... when you do interleaving, anchor functions resolve to actual piel values at computed style time<br>
<kbabbitt> ... computed style doesn't have info to tell if there's an anchor reference<br>
<kbabbitt> ... if you keep magic bit for anchor function, it doesn't round-trip<br>
<kbabbitt> ... div.style.bottom = gCS.bottom, it goes away, would be bad<br>
<kbabbitt> iank_: abspos doesn't reoundtrip insets today anyway<br>
<kbabbitt> ... does it?<br>
<kbabbitt> TabAtkins: yeah?<br>
<kbabbitt> emilio: auto resolves<br>
<Snugug> I'm being told by someone in WICG that they're looking for CSS representation for the scrollbar feature. I'm not sure I'm the right person to go down and represent the WG, but if no one else is able to do so I will<br>
<kbabbitt> iank_: shrink to fit vs stretch ... you % will resolve differently<br>
<kbabbitt> fantasai: won't change % resolution because that's based on CB<br>
<kbabbitt> ... resolving auto might have some effect<br>
<kbabbitt> ... anything else should round-trip<br>
<Snugug> will do.<br>
<kbabbitt> iank_: I would be fine with losing the round-tripping<br>
<kbabbitt> emilio: pretty unfortunate, this would also be the case even with typed om that doesn't do resolved value shenanigans<br>
<kbabbitt> ... typed om doesn't resolve auto<br>
<kbabbitt> ... but does resolve anchor to px<br>
<kbabbitt> ... due to how anchor is defined<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to suggest using position-area OR position-try<br>
<kbabbitt> fantasai: the problem we're running into doesn't happen with TabAtkins example<br>
<kbabbitt> ... problem happens when we add to that example something like position-try<br>
<kbabbitt> ... so what if we trigger SCB on having either position-area non-initial or position-try non-initial<br>
<kbabbitt> ... would that solve teh core problem?<br>
<kbabbitt> iank_: don't think that works because available space is different between 2 examples<br>
<kbabbitt> .... if it' sleft or right, available space of local CB vs scroillable CB is 2 very diferent things<br>
<kbabbitt> ... shirnbk to fit will be different<br>
<kbabbitt> TabAtkins: height % will also be different<br>
<kbabbitt> fantasai: changing the resolution of % also, a lot of things to trigger based on<br>
<kbabbitt> ... also you have the case of, if you use anchor func with named anchor vs implicit anchor, you get different layout behavior alos<br>
<kbabbitt> ... just keying off position anchor is for layout puyrposes is not the right switch<br>
<kbabbitt> iank_: you get different behavior anyway if you use position-anchor<br>
<kbabbitt> ... very big layout switch anyway<br>
<kbabbitt> astearns: can we go back to miriam's suggestion of requiring an opt-in for anchor instead of this implicit anchor behavior?<br>
<kbabbitt> fantasai: position-area span-all is an explicit opt-in<br>
<kbabbitt> TabAtkins: problem is, abspos behavior today is straight up broken for most anchor related use cases<br>
<kbabbitt> ... anything that cares about the space breaks in most cases if you use local CB of your scorller<br>
<kbabbitt> ... taht's why we want to be forgiing in opting into scrollable CB instead<br>
<kbabbitt> ... explicit opt in a<br>
<kbabbitt> ... problem when you have other things that opt into anchor pos<br>
<kbabbitt> miriam: we have lots of things that opt into grid but you still have to set display grid and that' suyseful<br>
<kbabbitt> astearns: and we're tying ourselves into knots on all possible triggers for anchor pos<br>
<emilio> q+<br>
<kbabbitt> ... do like simplicity of single property that has to be set to something, that gets you into new anchor pos behavior<br>
<kbabbitt> TabAtkins: very likely can't key all anchor pos off some new opt-in, been shipped in several browsers for quite a while<br>
<kbabbitt> astearns: just changing implicit anchor behavior to require an opt-in with the property that has that anchor choice built in<br>
<kbabbitt> ... taking the implicit anchor and making it an explicit choice<br>
<kbabbitt> fantasai: initial value of position-anchor should be none?<br>
<kbabbitt> astearns: yes<br>
<kbabbitt> miriam: that's what I was saying<br>
<kbabbitt> iank_: would likely be fine with popver if we did that and adde dposition anchor implicit for that<br>
<kbabbitt> ... popovers are position fixed by default and don't have this behavior<br>
<emilio> q-<br>
<kbabbitt> ... probably fine to be honest<br>
<kbabbitt> TabAtkins: popover is just a matter of one more line in UA stylesheet, should be fine<br>
<kbabbitt> fantasai: whole point of defining implicit anchor is so you don't ahve to think about that connection<br>
<kbabbitt> miriam: disagree, you still don't have to know what the name of it is<br>
<kbabbitt> ... still useful to get automatic anchor even if you explicitly opt in<br>
<kbabbitt> flackr: yes, that was main reason it's useful<br>
<kbabbitt> astearns: of the things we've discussed, I think that's the most promising thing<br>
<kbabbitt> ... I think we should either resolve on auto anchor selection being a value you have to put in property, or take this back to the issue and move on<br>
<kbabbitt> TabAtkins: good with first option<br>
<kbabbitt> fantasai: would like to hear from kizu<br>
<kbabbitt> iank_: I'm okay with it<br>
<kbabbitt> kizu: <sigh><br>
<kbabbitt> miriam: I agree with kizu<br>
<adamargyle> need demos? need to see something…<br>
<kbabbitt> kizu: I like the idea of making the position-anchor none by default<br>
<kbabbitt> ... for pseudo elements you opt in by doing this or you could use implicit keyword inside anchor function as well<br>
<kbabbitt> ... so you don't have to mention as position-anchor<br>
<flackr> if it's none by default do we need to use the keyword implicit or is it just auto?<br>
<kbabbitt> TabAtkins: we would add the implicit keyword as one of the things we put in implicit anchor<br>
<kbabbitt> ... right now if you omit you get popover behavior<br>
<iank_> thats a good idea.<br>
<kbabbitt> fantasai: if we change this behavior to not create binding by default, inital value should be none<br>
<TabAtkins> default-anchor initial value becomes `none`. `auto` selects an implicit anchor.<br>
<kbabbitt> astearns: proposed resolution is that the default value of position-anchor is `none` but you can use `auto` to opt in to implicit anchor<br>
<kbabbitt> fantasai: so we add new value, and change initial value<br>
<kbabbitt> ... and also add to stylesheet for popver<br>
<kbabbitt> astearns: any concerns?<br>
<kbabbitt> fantasai: don't love it but can live with it<br>
<kbabbitt> TabAtkins: this is my proposal with words changed<br>
<kbabbitt> fantasai: no it's a little diffreent, we don't have synonyms<br>
<kbabbitt> astearns: objections?<br>
<kbabbitt> nt1m: if this new value is new default, why do we need to add to stylesheet?<br>
<kbabbitt> emilio: popover wants old behavior<br>
<kbabbitt> fantasai: popover would continue to have implicit anchor you could just use, anything else with implicit anchor you need to opt in<br>
<kbabbitt> ... :before and after which create a binding will no longer do that<br>
<kbabbitt> nt1m: we'd be breaking all the demos that apply anchor pos on pseudo elements?<br>
<kbabbitt> emilio: the ones that don't use position-area<br>
<kbabbitt> fantasai: we didn't resolve that position-area would also be a switch<br>
<kbabbitt> [crosstalk]<br>
<kbabbitt> fantasai: demos that currently use before and after ...<br>
<kbabbitt> TabAtkins: not safe to do current behavior<br>
<kbabbitt> iank_: and I don't think we've shipped before and after behavior<br>
<kbabbitt> astearns: I hear some reservations but no objections<br>
<kbabbitt> RESOLVED: add none value to position-anchor, make it the initial value, change UA stylesheet for popover<br>
<Snugug> @astearns The meeting had wrapped by the time I got down there and it was unclear from those who were still in the room whether the topic had been presented or what the results were<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-3525018605 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 November 2025 03:10:58 UTC