[css-position][css-anchor-position] Splitting Scrollable Containing Blocks

[fantasai]

When reviewing some incorrect testcases about the interaction of anchor positioning and scroll containers, and also the considering #10861, Tab and I concluded that there are multiple behaviors that are needed when attaching an abspos to a scrollable containing block, and we should introduce a switch. (Ian and Tab also came to this conclusion in a different discussion.)

The three possible behaviors for a scrollable containing block are:

• attach to the scrollport, do not scroll with the content ("outside" the scroller)
• attach to the "initial containing block" (coinciding with the scrollport at the initial scroll position), scroll with the content ("inside" the scroller)
• attach to the "scrollable containing block" (roughly the scrollable overflow area), scroll with the content

Our proposal is to split positioning into three controls:

• position-type: static | relative | sticky | absolute
• position-attachment: auto | local | fixed | scroll
• position-container: nearest | farthest | <custom-ident>

The position-container property was introduced in #9868

The position-attachment values are as follows:

• local - the "initial containing block" of the scroller, the ICB at the root
• fixed - the fixed scrollport itself, the viewport at the root.
• scroll - the scrollable overflow area, per [css-align][css-position][css-anchor-position] Introduce "document containing block" for some purposes? #10861
• auto - scroll if using anchor positioning or local otherwise (for compat)

position would accept <'position-type'> || <'position-attachment'> || <'position-container'> and resolve as follows (setting omitted values to initial):

• static -> position-type: static
• sticky -> position-type: sticky
• relative -> position-type: relative
• absolute -> position-type: absolute; position-container: nearest; position-attachment: auto
• fixed -> position-type: absolute; position-container: farthest; position-attachment: fixed

For compat reasons, position-container: farthest; position-attachment: fixed may need to convert to local attachment if intercepted by a CB before the root (but it would be nice if we could not do this).

Doing this nicely will require shorthandifying position, though, so that's a topic we really do need to figure out. Working around it would be... awful.

[bfgeek]

Doing this nicely will require shorthandifying position, though, so that's a topic we really do need to figure out. Working around it would be... awful.

I don't think its that awful. If we accept an auto for both position-attachment and position-container, we can change the behaviour based on the position value - this is relatively straight forward that avoids shorthanding.

position-container: nearest | farthest | <custom-ident>

Its not clear to me the value in nearest / farthest by themselves, e.g. the switch that people use for that beahviour today is switching between absolute / fixed which shouldn't complicate that more. A simpler sytax could just be
position-container: auto | <custom-ident>

[bfgeek]

Also farthest would be kinda lying due to certain things forcing a fixed-pos containing block (transform/filters/containment/etc).

[tabatkins]

Also farthest would be kinda lying due to certain things forcing a fixed-pos containing block (transform/filters/containment/etc).

That's why we called it farthest rather than root, fwiw. Grab the farthest CB that you're capable of reaching, rather than the nearest one.

[css-meeting-bot]

The CSS Working Group just discussed [css-position][css-anchor-position] Splitting Scrollable Containing Blocks.

The full IRC log of that discussion

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

[fantasai]

Proposal is to accept what's outlined at the top, except only allowing the position property to be declared, i.e. not creating the longhands to be specified.

[tabatkins]

Tho note that position:fixed has to set both attachment and container, so that means we need to rename the fixed attachment value to avoid the clash. Calling it "viewport" might work.

[tabatkins]

Precise proposal:

position: <position-type> || <position-attachment> || <position-container>

<position-type> = static | relative | sticky | absolute | fixed
<position-attachment> = auto | local | scroll | viewport
<position-container> = nearest | farthest

• Temporarily removing the <dashed-ident> from "container", as that's a separate issue. We can add it back later.
• The fixed value causes an unspecified attachment/container to default to farthest and viewport. Otherwise it's identical to absolute.
• Other than the above, omitted values default to absolute, nearest, and auto.
• The property's initial value is still static, of course.

---

Another possible slight variant:

position: static | relative | sticky | fixed | [ absolute || <position-attachment> || <position-container> ]
(<position-container> and <position-attachment> as defined above)

• This disallow silly combinations of static/etc with attachment/container values, and leaves open the possibility of other type-specific controls (I think sticky has a chance to grow some more, for example)
• fixed also loses configurability, which is probably good. fixed viewport is redundant; fixed local is contradictory. It just "behaves as " absolute nearest viewport.