Re: [csswg-drafts] [css-overflow-5] Should ::scroll-marker pseudo-elements within skipped content-visibility: auto elements be discovered? (#11705)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> flackr: probably not what authors intend. so i'm proposing we find a way to make this work.<br>
&lt;TabAtkins> flackr: 1) make it similar to find-in-page, we don't skip the subtrees for finding scroll markers<br>
&lt;TabAtkins> s/florian/flackr/<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> flackr: could just say they're contianed and that's that, but i think author expects it<br>
&lt;emilio> TabAtkins: I agree about trying to work it out<br>
&lt;emilio> ... from author perspective the scroll marker is no longer "in the subtree"<br>
&lt;emilio> ... having containment applied to it would be [missed]<br>
&lt;TabAtkins> flackr: yeah, that would be the last point in my carveout<br>
&lt;emilio> s/[missed]/confusing<br>
&lt;emilio> q+<br>
&lt;emilio> flackr: so you agree with me?<br>
&lt;emilio> TabAtkins: yes<br>
&lt;astearns> ack fantasai<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: i'm a bit wary of introducing this kind of exceptions...<br>
&lt;TabAtkins> emilio: could make same argument about fixpos children. i think those don't escape<br>
&lt;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<br>
&lt;TabAtkins> emilio: they tend to bite us back<br>
&lt;emilio> astearns: is there anything else we'd need to apply this to? Seems a weird special-case<br>
&lt;andruud> q+<br>
&lt;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.<br>
&lt;emilio> flackr: dialogs are sorta similar<br>
&lt;TabAtkins> flackr: i think dialogs are similar<br>
&lt;TabAtkins> TabAtkins: that gets puts in the top layer, it escapes<br>
&lt;emilio> TabAtkins: for those things, it's box-tree rewriting<br>
&lt;emilio> ... we do it not very often but when we do it does escape<br>
&lt;emilio> ... fixedpos is different<br>
&lt;emilio> ... because those don't escape in the layout tree<br>
&lt;emilio> ... also if you're a fixed pos you can move them around without rendering effect<br>
&lt;emilio> ... same is not true of scroll markers<br>
&lt;emilio> q+<br>
&lt;astearns> ack andruud<br>
&lt;emilio> ... so I'm ok w/ fixed-pos getting contained but scroll-markers not being contained<br>
&lt;TabAtkins> andruud: does this mean that style skipping for c-v is just defeated for scrollable elements/<br>
&lt;emilio> andruud: does this mean that style skipping is defeated for scrollable elements?<br>
&lt;TabAtkins> flackr: for scrollable containers that have an active scroll-marker-group<br>
&lt;TabAtkins> andruud: so you'd know it on the scroller<br>
&lt;TabAtkins> flackr: yes. we'd still be able to skip style in the nromal case<br>
&lt;TabAtkins> andruud: are you worried that style and layout are now linked a bit thru CQs and anchorpos?<br>
&lt;TabAtkins> andruud: you can't really know the style until you do layout if there's a CQ<br>
&lt;TabAtkins> flackr: yeah, ijn those cases i suppose we'd be requiring the layout<br>
&lt;TabAtkins> flackr: but it is contained to things in that scrolling container<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: tho arguably, setting this on the root is kinda a use-case<br>
&lt;TabAtkins> was gonna point that out too :)<br>
&lt;TabAtkins> emilio: I think fixpos do get reparented in a way, we just say contain:layout establishes a CB for them<br>
&lt;TabAtkins> TabAtkins: yeah, a lot of things esteablish a CB for fixpos, they're easily interrupted<br>
&lt;TabAtkins> emilio: I suppose this adds another weird case where we do styling but don't fire transition events, etc<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> astearns: so not hearing great enthusiasm, but not hearing objections<br>
&lt;TabAtkins> astearns: supposed proposed resolution would be to take option 2, and attempt to come up with a spec?<br>
&lt;TabAtkins> flackr: yes, that's what I'm looking for. try to do it, see how it works out.<br>
&lt;TabAtkins> astearns: any objections to attempting option 2?<br>
&lt;TabAtkins> RESOLVED: Try option 2<br>
&lt;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.<br>
&lt;TabAtkins> astearns: right, worth trying<br>
&lt;emilio> scribe+<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11705#issuecomment-2669299007 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 19 February 2025 17:26:09 UTC