Re: [csswg-drafts] [css-scrollbars] What is "the background" (#10524)

The CSS Working Group just discussed `[css-scrollbars] What is "the background"`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> florian: a while back we talked aobut using transparent colors when setting scrollbar colors<br>
&lt;TabAtkins> florian: we resovled that if you set the transparent thumb, you see the track. if you set transparent track, you see the backgroudn of the element<br>
&lt;TabAtkins> florian: we didn't define waht actually is meant by "background"<br>
&lt;TabAtkins> florian: testing, we didn't mean "background", we seemed to mean "element".<br>
&lt;ChrisL> q+<br>
&lt;TabAtkins> florian: almost agreement in brwosers<br>
&lt;TabAtkins> florian: nuance, content of the element isn't seen, but that's just because it's clipped to the padding area so it's not there to *be* seen<br>
&lt;TabAtkins> florian: that's controlled by overflow-clip-margin, default is padding-box<br>
&lt;emilio> q+<br>
&lt;TabAtkins> florian: thus far I think Chrome and Firefox completely agree<br>
&lt;TabAtkins> florian: only one tiny difference, think it's a bug<br>
&lt;TabAtkins> florian: if you do background-attachment local, in Chrome the bg is clipped to the padding box.<br>
&lt;TabAtkins> florian: dont' think there's any spec justification for that<br>
&lt;TabAtkins> florian: wasn't meaningfully observable before, but in Chrome you can't see a local bg because it's clipped; in firefox you see the bg<br>
&lt;astearns> ack ChrisL<br>
&lt;TabAtkins> florian: just need to figure out how to define that stacking/painting<br>
&lt;TabAtkins> ChrisL: what we want is a term for "entire rendered content of the element"<br>
&lt;TabAtkins> florian: Might be a term for that already, just don't know it<br>
&lt;TabAtkins> q+<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: I don't think... overflow-clip-margin doesn't apply to scrollable boxes generally<br>
&lt;TabAtkins> emilio: but the rest i think is correct, and we should agree on this behavior<br>
&lt;astearns> ack TabAtkins<br>
&lt;emilio> TabAtkins: I think all that's necessary is defining when scrollbars are painted in the CSS stacking model<br>
&lt;emilio> florian: so we'd monkey-patch that algorithm from the scrollbars spec?<br>
&lt;emilio> TabAtkins: no, that's on another spec but yeah<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: I agree, but the specifics of where they're painted is maybe a bit weird...<br>
&lt;TabAtkins> emilio: need to dig into it<br>
&lt;TabAtkins> emilio: might be some cases where we'd intentionall put scrollbars over content they aren't usually over<br>
&lt;TabAtkins> emilio: will need to check<br>
&lt;TabAtkins> emilio: but i agree we need to define the right stacking order of scrollbars<br>
&lt;TabAtkins> astearns: so florian, you ahve a way forward<br>
&lt;TabAtkins> florian: yes, details TBD, but can agree that behind a transparent scrollbar you'll see the entire underlying content<br>
&lt;TabAtkins> florian: not just showing you one specific layer of the element<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> astearns: proposed: specify that transparent scrollbars show thru whatever's underneath them<br>
&lt;TabAtkins> emilio: checking, i think gecko puts classic and overlay scrollbars at a different stacking position<br>
&lt;TabAtkins> emilio: wrt element contents at least<br>
&lt;TabAtkins> astearns: so back to issue now<br>
</details>


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


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

Received on Thursday, 30 January 2025 00:05:07 UTC