- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 23:00:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-3] Should there be a special fixedpos ICB?`, and agreed to the following: * `RESOLVED: No change to the spec, position-attachment is defined the same way` <details><summary>The full IRC log of that discussion</summary> <emilio> iank_: in css-position there's two ICBs, one for fixed-pos and one for abs-pos<br> <emilio> ... blink and webkit don't have this distinction, we have the ICB and all fixed-pos and abs-pos get laid out in there<br> <TabAtkins> q+<br> <emilio> ... Gecko does, and it has behavior implications for anchor-pos (layout order is different)<br> <emilio> ... conceptually we don't need this, and with `position-attachment` I don't think we need this distinction<br> <emilio> TabAtkins: I remember why we put it in this concept<br> <Rossen> ack TabAtkins<br> <emilio> ... and it's to ensure that a fixedpos element can anchor to whatever the hell it wants<br> <emilio> ... otherwise fixed-pos and absposes can only anchor to earlier ones in the document<br> <emilio> ... it's a nice property that one way to make sure that your anchored thing can anchor to whatever is making it a fixedpos<br> <emilio> ... it's a nice get-out-of-jail-free card<br> <emilio> ... it'd be somewhat unfortunate to lose that<br> <emilio> ... but losing that means that an abspos can anchor to a fixpos assuming that order is correct<br> <emilio> iank_: I think the get-out-of-jail free card is top layer<br> <emilio> ... the distinction between abspos and fixedpos gets wacky when we allow abspos to attach the scrollport and so on<br> <emilio> ... and people use this on webkit / blink<br> <TabAtkins> emilio: I like the 2CB model, it explains clearly why fixpos don't scroll around<br> <TabAtkins> emilio: but I agree that, since we want make that tweakable for all scrollers with psoition-attacchment, it makes less sense to keep that distinction<br> <TabAtkins> emilio: so tldr I don't mind either way<br> <TabAtkins> emilio: I like the gecko behavior<br> <TabAtkins> emilio: it's also a bit tricky because a top-layer abspos lays out after a non-top-layer fixpos<br> <TabAtkins> iank_: that's why I prefer using top layer as the get out of fail free<br> <TabAtkins> emilio: does top layer affect layout order...?<br> <TabAtkins> iank_: yes<br> <TabAtkins> emilio: hm not sure that's in the spec<br> <TabAtkins> emilio: hm I guess it does because it says they all lay out after the root<br> <TabAtkins> iank_: yeah<br> <TabAtkins> iank_: we didn't implement this, then got complains that top-layer things weren't anchoring to stuff on the page.<br> <TabAtkins> iank_: so we changed that beahvior to sort based on taht<br> <emilio> TabAtkins: I think that's in position-4<br> <Rossen> ack fantasai<br> <emilio> fantasai: is the only way this is observable via anchor-pos?<br> <emilio> emilio: maybe paint order?<br> <emilio> Rossen: transforms?<br> <emilio> emilio: transforms don't because they create abspos and fixed-pos cb<br> <fantasai> emilio: Depending on how you define this new model, new thing would be paint order<br> <astearns> hit testing? (perhaps that’s just paint-order)<br> <fantasai> emilio: If you store them in teh same in-flow list, they interleave together<br> <fantasai> emilio: I think Gecko you cannot get that behavior because fixedpos will always paint afterwards<br> <fantasai> emilio: So that may need some testing<br> <fantasai> emilio: Might be more subtle than saying it's the same containing block<br> <smfr> is it web compatible to change this then?<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14640<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14641<br> <fantasai> iank_: They interleave in the testcase<br> <fantasai> emilio: Right, because paint order is the DOM order.<br> <fantasai> emilio: they're in the same stacking context<br> <Rossen> ack fantasai<br> <emilio> fantasai: when we made this distinction was in order to resolve anchoring dependencies<br> <emilio> ... if we merge these into the same list it'd mean the dependency order with abspos is going to go back into the dom order<br> <emilio> ... but I think we have a fair amount of evidence that the DOM order is very confusing?<br> <emilio> ... not sure it's better<br> <emilio> ... rather than distinguishing between fixed-pos vs. abspos<br> <emilio> iank_: I think that's a different question?<br> <emilio> ... you don't need two cbs to order the layout<br> <emilio> emilio: but the effect is the same right?<br> <emilio> iank_: not necessarily?<br> <fantasai> iank_: Get complex with selection<br> <fantasai> emilio: abspos position-attachment vs fixedpos ...<br> <fantasai> iank_: The capability of selecting your position container<br> <fantasai> iank_: then you don't necessarily know all the absposes ahead of time, for example<br> <fantasai> iank_: You only know after performing layout onthe subtree what all of the abspsoes are going to be, bubble up to CB<br> <fantasai> emilio: Depends how you implement it<br> <fantasai> iank_: For us it's true<br> <fantasai> iank_: Today it's fine because fixed will only introduce more fixedpos<br> <fantasai> iank_: But with the capability of an abspos to punch through that fixedpos, you might have absposes appearing after fixedpos<br> <astearns> ack fantasai<br> <emilio> fantasai: I think you're talking about having a descendant of a fixedpos but it's abspos it'd be functionally fixedpos, but with the ability to select the cb it can escape<br> <emilio> ... I think we can disable that<br> <emilio> q+<br> <emilio> ... It could go to a higher level CB<br> <emilio> ... a fixedpos in a descendant scroller<br> <emilio> ... but I think it'd be reasonable to switch down to an abspos in the same CB<br> <emilio> ... this could be impossible and we don't need to allow that<br> <emilio> TabAtkins: agreed, it's intended to move up the tree not sideways or down<br> <fantasai> TabAtkins: agreed. This is supposed to allow you to move up, not sideways or down<br> <emilio> iank_: if you don't have that rule abspos inside fixedpos couldn't go buck to the ICB<br> <emilio> ... today all abspos will get captured by the fixedpos<br> <fantasai> iank_: but they could punch through to become abspos at the ICB<br> <emilio> emilio: with position-container might punch to the fixed CB, so they'd be fixedpos<br> <emilio> iank_: if we want fixedpos to layout after abspos we don't need to be two CB<br> <astearns> ack emilio<br> <fantasai> emilio: SOme of this you can alaready do in top layer, which already escapes the fixedpos tree<br> <fantasai> emilio: and that's sorta well-defined?<br> <fantasai> iank_: Top layer reparents the whole element, so it's pretty different<br> <emilio> iank_: top layer reparents so it's pretty different<br> <TabAtkins> (the whole box, rather)<br> <fantasai> astearns: I wonder if we should punt on these future extensions of selecting your containing block<br> <fantasai> astearns: it's good to have an idea of what we're up against<br> <fantasai> astearns: but continue on whether to have the two ICB model<br> <fantasai> emilio: Right now no difference between two ICB model and fixedpos-layout-after-abspos<br> <fantasai> iank_: Wrt future-proofing, there's valid cases<br> <fantasai> iank_: if there are transforms trapping everything, then valid to fixedpos after abspos<br> <fantasai> iank_: Might be useful for web developers, when they get something trapped by someting establishing a CB<br> <fantasai> iank_: and they know that position:fixed will always be after the absposes<br> <fantasai> emilio: My point is, the 2-CB model is not different from ICB lays out fixedpos after abspos<br> <TabAtkins> this is just because, *without* the fixpos trapping, the fixpos would definitely be higher in CB tree than the abspos and thus would be anchor able?<br> <fantasai> emilio: You're aruging that if we were to define, it would be useful for fixedpos after abspos even if you're not in the ICB<br> <fantasai> iank_: I want to be consistent<br> <fantasai> emilio: fixedpos trapped by transform isn't a fixedpos to me. it's an abspos<br> <astearns> ack fantasai<br> <emilio> fantasai: I think we actually we need to figure out the position-container interactions here<br> <emilio> ... the reason for describing this model is going to be to make that make sense<br> <emilio> ... because that's a complexification of the current spec<br> <emilio> ... the idea of the fixedpos CB containing the abspos CB makes tons of sense for position-container<br> <emilio> ... and then position-container's ability is to get you to a higher one<br> <emilio> ... so if you're in a fixed-pos element that element's CB is the fixed-pos's cb<br> <emilio> ... not the abspos's cb of the scroller<br> <emilio> ... so you can't put stuff inside the scroller from the fixedpos, you can only go up<br> <emilio> ... and I think that would help you to implement the restriction you want<br> <emilio> +1<br> <fantasai> emilio: If we treat the scroller's containing blocks like this, like an outer thing that represents the thing outside the scroll content, and the inner thing which the abspos currently attached to<br> <fantasai> emilio: that makes sense<br> <fantasai> emilio: position-attachment and stuff would allow you to attach to either of them<br> <fantasai> emilio: position-container would let you jump higher up<br> <fantasai> emilio: I think that model makes sense to me<br> <fantasai> TabAtkins: So intention is that we do want to allow an abspos that's currently child of fixedpos to set its position-attachemnt to the fixed cb, and contianer to root, so it becomes a fellow fixedpos. But not come out and become scrollable.<br> <fantasai> TabAtkins: So it's ok if it jumps out of fixedpos and stays fixedpos<br> <fantasai> emilio: yeah<br> <fantasai> emilio: It's basically treating scroller as an outer box and an inner box. Abspos attaches to inner box, and fixedpos to outer box<br> <fantasai> TabAtkins: it does mean an abspos can never anchor to a fixedpos with the same cb container<br> <fantasai> emilio: which is what the spec currently says<br> <fantasai> emilio: unless it goes top-layer<br> <emilio> iank_: if we go through this model it's still implementable<br> <emilio> ... if we have this model we have to be careful about allowing thing to attach to the scrollport and what not<br> <emilio> ... being backwards compat with how they contribute to scrollable overflow<br> <TabAtkins> (iirc, our fixpos model is that it uses the ICB + a scroll adjustment to keep it still)<br> <emilio> emilio: does fixed-pos contribute to scrollable-cb<br> <emilio> TabAtkins: the fixedpos that gets trapped by transforms<br> <emilio> iank_: I thought we were extending this model to scrollers<br> <TabAtkins> (I think we should make the new feature opt out, and it's a special legacy case just of `position:fixed` specifically)<br> <emilio> fantasai: there's two alternatives, one is to describe the current behavior which is that fixed-pos trapped by transform is an abspos<br> <emilio> ... the other is that now that we have the capability of creating a fixedpos for a transformed scroller it won't become a transformed scroller it'd become a fixedpos in the transformed scroller<br> <emilio> ... if it's web compat we should maybe try to do it because it's closer to author intent<br> <emilio> emilio: but that'd be a big change in behavior in whichever model we choose<br> <fantasai> emilio: because right now it will scroll<br> <emilio> iank_: but if position-attachment is auto it'll do that but if you set a fixedpos to explicitly scroll then you do want to layout that after everything else<br> <emilio> TabAtkins: need to be clear about the combination<br> <emilio> iank_: oh, using the wrong one. position-attachment: fixed<br> <emilio> ... so if you say I want to be fixed to the scrollable CB<br> <TabAtkins> emilio: you do get that beahvior ou tofu the 2-CB model, yes<br> <emilio> ... you need to layout the fixedpos after everything else<br> <emilio> fantasai: in any case that's probably a different issue<br> <TabAtkins> (I don't have a ton of opinion either way on this fwiw, i'm okay with either result.)<br> <emilio> ... I think right now if they are trapped they behave as abspos<br> <emilio> ... to the extent they do they'd attach to the abspos cb<br> <emilio> iank_: we need to be careful with absposes punching through the fixedpos cb<br> <emilio> ... we need to be careful about what that behaviors that triggers<br> <emilio> ... does it contribute to scrollable overflow etc<br> <fantasai> emilio: fixedpos doesn't contribute to scrollable overflow<br> <emilio> fantasai: if you're a descendant of the fixedpos stuff you don't can't go back to the abspos cb<br> <emilio> TabAtkins: what we're saying is that the key distinction between abspos and fixedpos is which CB they attach to<br> <fantasai> PROPOSED: Define position-attachment in terms of these two nested CBs.<br> <emilio> PROPOSED: No change to the spec, position-attachment is defined the same way<br> <emilio> RESOLVED: No change to the spec, position-attachment is defined the same way<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13468#issuecomment-4180912860 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 23:00:10 UTC