- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 May 2023 17:01:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] How does overflow-clip-margin: border-box behave on a scroll container?`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> miriam: emilio raised this, fantasai agenda+'d it<br> <iank_> +1<br> <TabAtkins> emilio: I'm fine with "it doesn't apply to scrollable boxes"<br> <TabAtkins> emilio: So when I filed this, I was wondering...<br> <TabAtkins> emilio: There are some elements that need to clip, even tho they're scrollable they clip to anothe rbox that isn't the padding box<br> <TabAtkins> fantasai: Issue is about whther overflow-clip-margin should apply to scroll containers<br> <TabAtkins> fantasai: Applying it brings up a lot of interesting questions<br> <TabAtkins> fantasai: Where does the scrollbar go. If you croll to the top/bottom is the content in the padding area clipped, or is the scroll area reduced so it's viewable. Etc.<br> <TabAtkins> fantasai: There's a comment from Matthew Perry where he outlines the desire for this feature, and outlines a set of behaviors that seem to amke sense to them.<br> <TabAtkins> fantasai: Scrollable area and viewport are both... Never mind, follow the examples.<br> <TabAtkins> fantasai: He wants things scrollable to be viewable until it's outside the scrollable margin.<br> <TabAtkins> fantasai: I thin kif it's within the box it has a layout impact...? It's not clear to me exactly.<br> <TabAtkins> flackr: I don't think it has to.<br> <TabAtkins> fantasai: If it doesn't have a layout impact, you can't see all the content unless you know to put enough padding in the content.<br> <TabAtkins> flackr: Right.<br> <TabAtkins> fantasai: So I think it probably makes more sense to effectively increase the size of the box to the content area.<br> <TabAtkins> fantasai: So I think the q is - do we want to figure out how to make this work? Or just define it to not work?<br> <TabAtkins> flackr: I think there are a lot of UIs that would benefit from this, and we should try to make it work.<br> <TabAtkins> iank_: Can you give an example?<br> <TabAtkins> flackr: This is a good way to handle cases where you want some visuals that show up above your scrolled content, but your scrollbar doesn't, so the image in Mathhew's comment shows an example there with a chat widget where the text scrolls under the header (and is blurred by a backdrop filter) but the scrollbar doesn't.<br> <TabAtkins> iank_: That could also be solved with a z-index fix to the scrollbar, maybe? Is this th eprimary driver?<br> <TabAtkins> flackr: Not the zindex, it's the physical size of the scrollbar should be smaller than the visible sie of the scrolled content<br> <TabAtkins> flackr: In the chat support widget exapmle, the scrollbar starts below the header. The header is outside the scroller.<br> <bramus> +1 to this example/use-case. I needed something like this just recently.<br> <TabAtkins> flackr: I see a lot of sites that have this issue where scrollbars don't line up with their visual affordances, and I think this API provides a path to fix that.<br> <emilio> q<br> <emilio> q+<br> <TabAtkins> iank_: My problem is overflow-clip-margin can go negative, and that brings up andditional qs<br> <TabAtkins> flackr: there may be other ways to do this<br> <TabAtkins> iank_: This doesn't feel like o-c-m to me but i could be wrong<br> <TabAtkins> flackr: The chat widget would have an ocm of -(header size).<br> <TabAtkins> flackr: Or, postive. whatever makes stuff outside the scroller visible<br> <miriam> ack emilio<br> <TabAtkins> emilio: We do have a property already to specify the scroll distance to bring elements into view<br> <bramus> q+<br> <TabAtkins> emilio: The use-case for th eheader seems like we should use that?<br> <TabAtkins> emilio: scroll-padding<br> <TabAtkins> emilio: So it seems there's a use-case to maybe put the scrollbar only in the scroll-padding area<br> <TabAtkins> emilio: May be another way of solving this<br> <flackr> q+<br> <TabAtkins> emilio: Haven't made up my mind about making the scroller smaller and content overflowing it, which is kinda weird, or tweak the positioning of the scrollbar via scroll-padding<br> <iank_> a control to shift the scrollbar seems slightly better<br> <miriam> ack bramus<br> <TabAtkins> bramus: Maybe another approach is instead of specifying distances is to specify "overflow on x-axis" is simple visible and a wrapper around it would clip it?<br> <flackr> +1 I was thinking a common pattern would be an ancestor applies a clip so that it doesn't infinitely overflow<br> <TabAtkins> bramus: In the chat support widget, there's a wrapper around the whole thing that's preventing the chat content from being visible<br> <flackr> q-<br> <TabAtkins> bramus: That avoids the concern about numbers.<br> <miriam> ack fantasai<br> <Zakim> fantasai, you wanted to say we should re-use extended <position> and to<br> <TabAtkins> fantasai: Using specific overflow-clip-margin is problematic, you shouldn't be trying to predict fixed pixel values<br> <TabAtkins> fantasai: Makes it incompatible with allowing wrapping, etc.<br> <TabAtkins> fantasai: So I don't know this is a good fit for th euse-case, but I don't know what the right solution is either.<br> <TabAtkins> miriam: I also don't necessarily think scroll-padding is right here, it defaults where to scroll to. Here you still want to scroll to the top, just want things to be able to scroll past that position.<br> <flackr> q+<br> <TabAtkins> fantasai: maybe now we need scroll-scope that hoists the layout scope of a descendant scroll container?<br> <miriam> ack flackr<br> <TabAtkins> flackr: My expectation is the way devs will use this is they have an ancestor that still clips the content, and having pixel values is not desirable<br> <TabAtkins> flackr: Maybe you make scrollable overflow visible and it's clipped by an ancestor instead.<br> <bramus> `overflow: scroll-visible` 🤨<br> <TabAtkins> miriam: So it sounds we're moving in the direction of a new property, rather than re-using o-c-m?<br> <TabAtkins> miriam: Do we want to resolve on the o-c-m behavior, and open a new issue for the remaining cases we still want to handle?<br> <TabAtkins> emilio: I think o-c-m isn't necessarily the right proeprty for this use-case, so acknowledging we want to solve them and open a separate issue probably makes more sense.<br> <miriam> ack fantasai<br> <Zakim> fantasai, you wanted to note the two suggestions<br> <TabAtkins> fantasai: Two side suggestions<br> <TabAtkins> fantasai: from bramus, `overflow: scroll-visible;`<br> <TabAtkins> fantasai: from someone else, a keyword to o-c-m (`infinite`?)<br> <flackr> overflow-clip-margin: infinite was me :-)<br> <PaulG> q+<br> <miriam> ack PaulG<br> <TabAtkins> PaulG: If something is beneath the margin, and o-c-m is set, and there's something interactive in that text (a link), is is possible for that to come into focus when tabbed? Or will it only scroll to its normal limit and not come further in due to the clip?<br> <argyle> q+<br> <TabAtkins> flackr: Not 100% sure I followed, but assuming it's just a visual clip change, then you wouldn't be able to scroll to the new area.<br> <TabAtkins> PaulG: Sounds unhelpful, yeah.<br> <TabAtkins> flackr: Right, the other solutions expand the clip instead.<br> <TabAtkins> argyle: Another use-case. I have shadows on boxes inside of scrollers, I'd like them to leak out. Right now they're clipped.<br> <TabAtkins> argyle: So similar case, I want the scrollport to contain and create a scrollable area, but not clip paint.<br> <TabAtkins> miriam: And w'er eat time, we'll take 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/7246#issuecomment-1551763970 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 May 2023 17:01:26 UTC