[css-overflow-5] Should ::scroll-marker pseudo-elements within skipped content-visibility: auto elements be discovered?

[flackr]

If you have ::scroll-marker pseudo-elements declared on elements within content-visibility: auto, what should happen? Consider a simple demo (view demo page):

<style>
.scroller { scroll-marker-group: after; }
.scroller > * { content-visibility: auto; }
h1::scroll-marker { content: ""; }
</style>
<div class=scroller>
  <div><h1>1</h1></div>
  <div><h1>2</h1></div>
  <!-- ... -->
  <div><h1>n</h1></div>
</div>

We have two main options:

1. Ignore them when they are skipped. This falls naturally out of the spec since skipped objects have style containment and so we shouldn't discover these markers, however this would result in the markers in the marker group changing as you scroll based on what is currently skipped. Authors could work around this by ensuring that they create markers on or above the element with content-visibility: auto (e.g. on the <div> elements in the above example).
2. Spec that we should discover these. We could do this in a similar way to how the spec requires that content-visibility: auto is still discoverable to find in page, tab order, etc. In particular, this means we would need to:
   1. Always compute style within content-visibility: auto when the nearest ancestor scroll container is not skipped and has a non-none scroll-marker-group property value.
   2. Either compute layout, or define that when computing the :target-current ::scroll-marker that we use the scroll into view position of the nearest non-skipped ancestor.
   3. Consider how to allow this considering the skipped content is supposed to be contain: style layout paint size.

[flackr]

Putting my web author hat on, having the elements discoverable (Option 2) feels like it would be easier to work with, and I think using the geometry from the ancestor might still allow us to still skip layout without affecting what is the current marker - since when a marker is close to being current it will no longer be skipped. However, I could construct a degenerate case where the vertical positions are different in a horizontal carousel leading to a different current target based on whether it is skipped or not.

[vmpstr]

To add a couple things to solve for 2:

• If just styling, we need to make sure that there is no scroller between the ::scroll-marker and the scroller that we want this marker to go into (ie discovering the right scroller for the marker under c-v auto).
• If the scroll-marker-group is sufficiently far away from the scroller then dealing with the fact that the scroller itself may have content-visibility: auto that skips it

[flackr]

Adding to the agenda to get consensus on which way we think we should go:

The benefits of option 1 are it's easy to spec, implement, and it ensures no degradation of how much content-visibility: auto content we can skip even when you use scroll-marker-group. Authors may be able to work around the limitation.

The main benefit of option 2 is that content-visibility: auto won't have weird side effects on visible content (hiding markers) when used above content creating scroll markers - it will "just work" as if the content is there as it does for find in page. However, the cost is that content-visibility will not be able to skip as much when you use scroll-marker-group

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Should ::scroll-marker pseudo-elements within skipped content-visibility: auto elements be discovered?, and agreed to the following:

• RESOLVED: Try option 2

The full IRC log of that discussion

<TabAtkins> flackr: it's common practice now to have content-visibility:auto on your list items fo rlong lists, so we skip painting ofr offscreen
<TabAtkins> florian: but if you have content in there that produces a scroll marker, as you scroll you'll be adding/removing markers from scroll-marker-group
<TabAtkins> flackr: probably not what authors intend. so i'm proposing we find a way to make this work.
<TabAtkins> flackr: 1) make it similar to find-in-page, we don't skip the subtrees for finding scroll markers
<TabAtkins> s/florian/flackr/
<TabAtkins> flackr: 2) use the scrollIntoView() psoition of the non-skipped ancestor of the marker for determining when the marker is active, this lets us still skip layout
<TabAtkins> flackr: finally, spec says put a bunch of containment on skipped elements. scroll markers are a bit of an exception - need to specify they paint even if they're in a paint containment
<TabAtkins> flackr: could just say they're contianed and that's that, but i think author expects it
<emilio> TabAtkins: I agree about trying to work it out
<emilio> ... from author perspective the scroll marker is no longer "in the subtree"
<emilio> ... having containment applied to it would be [missed]
<TabAtkins> flackr: yeah, that would be the last point in my carveout
<emilio> s/[missed]/confusing
<emilio> q+
<emilio> flackr: so you agree with me?
<emilio> TabAtkins: yes
<astearns> ack fantasai
<astearns> ack emilio
<TabAtkins> emilio: i'm a bit wary of introducing this kind of exceptions...
<TabAtkins> emilio: could make same argument about fixpos children. i think those don't escape
<TabAtkins> emilio: i'm not opposed to try and make this work, i agree it would be nice, i'm justs wary of the implications
<TabAtkins> emilio: they tend to bite us back
<emilio> astearns: is there anything else we'd need to apply this to? Seems a weird special-case
<andruud> q+
<TabAtkins> astearns: that was my concern too. is there anything else we'd need to apply this to? seems a little strange to have this carveout just for scroll marker.
<emilio> flackr: dialogs are sorta similar
<TabAtkins> flackr: i think dialogs are similar
<TabAtkins> TabAtkins: that gets puts in the top layer, it escapes
<emilio> TabAtkins: for those things, it's box-tree rewriting
<emilio> ... we do it not very often but when we do it does escape
<emilio> ... fixedpos is different
<emilio> ... because those don't escape in the layout tree
<emilio> ... also if you're a fixed pos you can move them around without rendering effect
<emilio> ... same is not true of scroll markers
<emilio> q+
<astearns> ack andruud
<emilio> ... so I'm ok w/ fixed-pos getting contained but scroll-markers not being contained
<TabAtkins> andruud: does this mean that style skipping for c-v is just defeated for scrollable elements/
<emilio> andruud: does this mean that style skipping is defeated for scrollable elements?
<TabAtkins> flackr: for scrollable containers that have an active scroll-marker-group
<TabAtkins> andruud: so you'd know it on the scroller
<TabAtkins> flackr: yes. we'd still be able to skip style in the nromal case
<TabAtkins> andruud: are you worried that style and layout are now linked a bit thru CQs and anchorpos?
<TabAtkins> andruud: you can't really know the style until you do layout if there's a CQ
<TabAtkins> flackr: yeah, ijn those cases i suppose we'd be requiring the layout
<TabAtkins> flackr: but it is contained to things in that scrolling container
<astearns> ack emilio
<TabAtkins> emilio: tho arguably, setting this on the root is kinda a use-case
<TabAtkins> was gonna point that out too :)
<TabAtkins> emilio: I think fixpos do get reparented in a way, we just say contain:layout establishes a CB for them
<TabAtkins> TabAtkins: yeah, a lot of things esteablish a CB for fixpos, they're easily interrupted
<TabAtkins> emilio: I suppose this adds another weird case where we do styling but don't fire transition events, etc
<TabAtkins> emilio: i do agree it would be nice to work, but will have a bunch of side effectws that might not be aware of right now
<TabAtkins> emilio: don't want to object to trying to figure this out. just think there's gonna be quirky edge cases and side effects
<TabAtkins> astearns: so not hearing great enthusiasm, but not hearing objections
<TabAtkins> astearns: supposed proposed resolution would be to take option 2, and attempt to come up with a spec?
<TabAtkins> flackr: yes, that's what I'm looking for. try to do it, see how it works out.
<TabAtkins> astearns: any objections to attempting option 2?
<TabAtkins> RESOLVED: Try option 2
<TabAtkins> flackr: and if it doesn't work out, we have option 1 which is easy to explain. option 2 is just nice for authors.
<TabAtkins> astearns: right, worth trying
<emilio> scribe+