- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 10:09:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position][css-anchor-position] Splitting Scrollable Containing Blocks`.
<details><summary>The full IRC log of that discussion</summary>
<emilio> fantasai: [whiteboard time]<br>
<emilio> fantasai: we have several different concepts of containing blocks<br>
<emilio> ... position: fixed is the viewport, outside of the scrollable area<br>
<emilio> ... position: absolute positions relative to the ICB<br>
<emilio> ... for a scroll container we have the ICB behavior<br>
<emilio> ... you can't get the fixed behavior unless you attach it to a wrapper around the scroll container<br>
<emilio> ... when we were discussing anchor pos, and your anchor is towards the bottom<br>
<emilio> ... the bottom of the icb is up there<br>
<emilio> ... we floor it at the anchor which ends up with a containing block rect which is zero-height<br>
<emilio> ... what you want is to create the nine-grid to create the thing to the whole scrollable area<br>
<emilio> ... and we resolved to do that (use a representation of the 'in-flow scrollable area')<br>
<emilio> ... for other scroll containers we don't have the ability to switch to the scrollport itself<br>
<emilio> ... for anchor positioning this is particularly important<br>
<emilio> q+<br>
<emilio> ... because you want to trigger fallback<br>
<emilio> ... so we need some kind of distinction<br>
<emilio> ... there are other use cases for this outside of anchor pos, it's just a more pressing issue with it because of fallback<br>
<emilio> ... so tab and i discussed syntactic switches, for {scrollport, icb-equivalent-thing, in-flow-scrollable-area}<br>
<emilio> ... in order to allow the author to distinguish this we need new syntax<br>
<emilio> ... we automatically decide on this for anchor pos<br>
<emilio> ... would be nice to allow authors to change it, also we can't for other absposes r/n<br>
<emilio> ... our proposal is to split `position` into three: `position-type: static/relative/sticky/absolute`<br>
<astearns> q+<br>
<emilio> ... `position-attachment: auto | local | fixed | scroll;` (local is icb, fixed is scrollport, scroll is in-flow-scrollable-area)<br>
<astearns> (all of these details are in the first comment in the issue)<br>
<emilio> ... `position-container: nearest | furthest | <custom-ident>;`<br>
<SebastianZ> q+<br>
<emilio> ... `nearest` gets you to nearest positioned element (abspos behavior), farthest is root (except when transformed) (fixedpos behavior)<br>
<emilio> ... `position: absolute` would expand to `absolute auto nearest`<br>
<emilio> ... `auto` behaves as `local` or `scroll` depending on whether you're anchor positioned<br>
<emilio> ... `position: fixed` would expand to `absolute fixed farthest`<br>
<emilio> ... that's the outline of the proposal<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: I wanted dto double-check some eof the shorthand expansions, but I think it looks reasonable overall<br>
<TabAtkins> emilio: if you have position-attachment:scroll and your CB isn't a scroll container...<br>
<TabAtkins> fantasai: the attachment values only change things for scroll containers. any other element, it does nothing<br>
<TabAtkins> emilio: i'd probably start without the container custom-ident, seems a bit complex<br>
<TabAtkins> fantasai: yeah, that's just from another issue. don't need it in the syntax right this moment<br>
<TabAtkins> emilio: and presumably these are paired..<br>
<TabAtkins> emilio: position-attachment and container are useless unless you specify pos:absolute<br>
<TabAtkins> emilio: but no reason to do them with position:relative<br>
<ydaniv> emilio: I find it weird that position:fixed expands to container<br>
<ydaniv> ... breaks my mental model<br>
<TabAtkins> emilio: my mental model of position-fixed is about the container rather than attachment, but that's because in impl we parent it to a box outside the root scroller<br>
<TabAtkins> emilio: if we impl this proposal we might change internally how we do pos:fixed to match this<br>
<TabAtkins> emilio: in general this makes sense tho<br>
<TabAtkins> emilio: probably want to leave out the custom ident stuff for now<br>
<TabAtkins> SebastianZ: [somewhat missed]<br>
<TabAtkins> emilio: you have the root scroller, it's a box outside of that which is the viewport<br>
<TabAtkins> emilio: we parent a fixpos to that "box"<br>
<TabAtkins> emilio: this changes it to instead attach to the scroller itself<br>
<TabAtkins> emilio: rather than a pretend ancestor<br>
<TabAtkins> q+<br>
<emilio> astearns: Couple things<br>
<emilio> ... you've raised the posibility of this isn't implementable because of the shorthandifying<br>
<emilio> ... iank_ says it's not so bad<br>
<emilio> ... but I don't think it addresses the issues we've hit in the past when shorthandifying<br>
<fantasai> s/not so bad/not so bad to avoid shorthanding/<br>
<emilio> TabAtkins: ian wants to not shorthandify, and says that is not so bad<br>
<fantasai> s/... iank_/TabAtkins: iank_<br>
<emilio> astearns: the other thing is that ian suggested for position container we could have just `auto | <custom-ident>`, but if we don't have the `<custom-ident>` we could leave that right?<br>
<astearns> ack astearns<br>
<emilio> fantasai: it's useful to attach to the root regardless<br>
<emilio> TabAtkins: being able to be at the root without being fixed<br>
<astearns> ack SebastianZ<br>
<emilio> ... is useful for anchor pos to be in the top layer<br>
<emilio> emilio: but the top layer doesn't scroll with the document right?<br>
<emilio> q+<br>
<emilio> SebastianZ: I think this could also solve changing the sticky position container<br>
<emilio> ... regarding the default position-container is weird, is there an auto?<br>
<emilio> fantasai: you don't need that. Assuming we can shorthandify then the expansion takes care of selecting the right default<br>
<emilio> ... we could make it auto, but it'd be nice to be consistent<br>
<emilio> emilio: you don't really need to shorthandify, and you could still not have auto<br>
<emilio> ... you'd omit the default<br>
<fantasai> s/consistent/avoid automagic where possible/<br>
<emilio> SebastianZ: re. nearest and farthest I was thinking viewport. For fixed positioned it's the viewport<br>
<emilio> fantasai: you can get trapped by a transform<br>
<emilio> SebastianZ: fair<br>
<bramus> q+<br>
<emilio> SebastianZ: regarding custom-ident you'd need a separate property for that<br>
<emilio> fantasai: yeah that'd be nice if we go down that path, and we'd need a separate<br>
<emilio> SebastianZ: why custom-ident and not dashed-ident?<br>
<emilio> fantasai: that's what we meant, should be dashed-ident<br>
<emilio> SebastianZ: finally do we want to extend position shorthand?<br>
<emilio> fantasai: yeah it should take the combination of all keywords<br>
<astearns> ack TabAtkins<br>
<emilio> TabAtkins: assuming that we can't shorthandify for a moment<br>
<emilio> ... we could add an auto value that keys off the position property<br>
<emilio> ... so position would remain as is, but `position-{container,attachment}` would have an auto value<br>
<emilio> ... which would choose the right default<br>
<emilio> emilio: I thought not shorthandifying would just expand the position syntax<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<emilio> TabAtkins: while I agree having the shorthand would be more ideal, I agree with iank_ that not shorthanding would be not as bad<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: want to confirm whether fixpos behavior includes the scrollbars gutters<br>
<TabAtkins> emilio: rn we have weird inconsistent beahvior<br>
<TabAtkins> emilio: should be sorted out<br>
<TabAtkins> emilio: assuming mostly what pos:fixed is doing...<br>
<TabAtkins> fantasai: should probably just match position:fixed yeah<br>
<TabAtkins> bramus: issue 8099 is concerned with that<br>
<TabAtkins> bramus: effect of scrollbar-gutter on the viewport<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/8099<br>
<TabAtkins> emilio: regarding shorthand vs not<br>
<TabAtkins> emilio: imagine we would expand 'position' longhand to just contain these extra values<br>
<TabAtkins> fantasai: they have to cascade and interact<br>
<TabAtkins> TabAtkins: you misunderstand, Emilio proposed putting the entire syntax into 'position'<br>
<TabAtkins> emilio: yeah, I think I kinda prefer that<br>
<TabAtkins> fantasai: so we'd have these "conceptual" longhands<br>
<TabAtkins> emilio: yeah, like display-inside vs outside<br>
<astearns> ack bramus<br>
<TabAtkins> fantasai: yeah that sounds better than independent properties that cascade badly<br>
<TabAtkins> bramus: also wanted to point to issue 7475<br>
<emilio> bramus: I also wanted to point to 7475<br>
<emilio> ... flackr filed it to give authors an option to where to pos-fix your elements<br>
<emilio> ... would this solve it?<br>
<emilio> fantasai: it's a different thing<br>
<emilio> ... but if we fix that it could be part of these properties<br>
<emilio> fantasai: I'd be ok with proposing the syntax model without the longhands, just all into position for now, then decide if we can/want to split it<br>
<emilio> ... so just the `position` syntax without the longhands<br>
<fantasai> Proposal would be `position: <type> || <attachment> || <container>`<br>
<fantasai> without the longhands possible<br>
<emilio> astearns: I'd be uncomfortable resolving on it r/n, let's take it back to the issue<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12607#issuecomment-3209880133 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 10:09:14 UTC