- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 15:43:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] add method to prevent elements from contributing to scrollable overflow`. <details><summary>The full IRC log of that discussion</summary> <emeyer> iank_: Developers would like a mechanism to ignore elements from scrollable overflow<br> <emeyer> …We also heard suggestions to ignore transforms for scrollable overflow purposes<br> <flackr> q+<br> <emeyer> …I think the only blocking thing here is, what do we call this?<br> <emeyer> …It's trivial to implement<br> <astearns> ack flackr<br> <emeyer> flackr: I raised the point there are parts of overflow that are significant<br> <emeyer> …I think it makes a big different for the name whether we include those or not<br> <emeyer> …That's why I suggested overflow-box<br> <emeyer> …Do we want to include snapping scroll into view<br> <emeyer> iank_: The specific case here is that a major site, because Chrome does transforms slightly more correctly, we snap to a transformed element which isn't the correct place<br> <emeyer> …The site wants to snap to the non-transformed place<br> <florian> q?<br> <emeyer> …We're only seen this with transforms; one option is to have a different property that says to ignore transforms for a bunch of operations<br> <emeyer> astearns: My concern is that you aren't defining a box, you're defining what the box pays attention to and what it ignores<br> <emeyer> …overflow-box-contribution seems more precise<br> <emeyer> iank_: I worry people will think it refers to which box model box you're using<br> <miriam> q+<br> <emeyer> flackr: I don't care about the name that much as long as we include those additional behaviors<br> <emeyer> …We do get into cases where we use a transform and get unstab le scroll position as a result<br> <emeyer> iank_: I think we use one or two properties<br> <emeyer> …The first property would just ignore transforms for snap alignement, scroll into view<br> <florian> q?<br> <florian> q+<br> <emeyer> …The second would ignore scrollable overflow contributions completely for the element<br> <astearns> ack miriam<br> <emeyer> flackr: Should decide if that should be two properties or two values on one proeprty<br> <emeyer> miriam: How does it work what it's in flow?<br> <emeyer> …If you set it to none, and it's the last thing on an autoflow, it doesn't trigger scrollbars<br> <emeyer> …But if you have something after it, it does?<br> <emeyer> iank_: If it's in flow, the in flow padding edge wraps everything onthe top layer and will still be scrollable<br> <emeyer> …Won't remove all side effects completely, but removes direct contribution of that element<br> <emeyer> …People can abspos things somewhere and it doesn't contribute<br> <astearns> ack florian<br> <emeyer> florian: If we go with two proeprties, the one that controls taking transforms into account probably shouldn't havce the word transform in its name<br> <emeyer> …You might want the behavior for more than transforms<br> <ydaniv> how about something like `layout-box`?<br> <flackr> q+<br> <emeyer> iank_: Initially, I wouldn't want to include relpos until we get stronger signals, since it's not as cleanly separated as transforms<br> <astearns> ack dbaron<br> <emeyer> florian: Sure, I just don't want to pick a name that would preculde handling that later<br> <khush> q+<br> <emeyer> dbaron: Agreed; there are cases where people want to ignore the transform while also using features you think they want to ignore<br> <astearns> ack flackr<br> <dbaron> s/want/might want/<br> <emeyer> flackr: More complicated answer is to ignore the animated value<br> <emeyer> …That wouldn't ignore scripted cases, and would be harder to compute, but<br> <khush> q-<br> <emeyer> iank_: I've thought about that case and I don't think we want to go down that path<br> <emeyer> flackr: Agreed<br> <astearns> ack fantasai<br> <emeyer> astearns: Sounds like we're at a single proeprty with multiple values<br> <emeyer> fantasai: For relpos situations, they could use transforms, so covering that covers most cases, I think<br> <emeyer> iank_: I'm coming around to this being two properties… but we still don't have any good names<br> <emeyer> astearns: What would the two properties do?<br> <emeyer> iank_: One switches off direct scrollable overflow contribution entirely, with values like normal and none<br> <fantasai> overflow-visibility: normal | none | transforms<br> <emeyer> …The other would affect things like snap align, scroll into view ignoring transforms<br> <emeyer> astearns: And the second one, you'd still have a scrollbar?<br> <emeyer> flackr: That would also be affected by the change in interpretation<br> <emeyer> …If you said you were ignoring transitions, you wouldn't get a scrollbar to scroll to the transformed position<br> <emeyer> astearns: Ian said this wasn't about the creation of the scrollable area; the first proeprty is the one that defines that<br> <fantasai> contain: overflow? transform-overflow: normal | none?<br> <emeyer> flackr: We can treat whether we're contributing as a separate thing<br> <emeyer> astearns: Then I don't get why they need to separate<br> <emeyer> iank_: It is a separate thing<br> <emeyer> …The first covers everything, and the second says "only ignore transform"<br> <khush> q+<br> <emeyer> ydaniv: We could use 'ignore-transforms' and something like layout<br> <emeyer> fantasai: I don't understand why they need to be separate either<br> <emeyer> iank_: The second affects things like snap areas<br> <ydaniv> s/and something/or something/<br> <dbaron> s/affects/also affects/<br> <emeyer> …If you use one property, what happens if you say none and it's a snap area<br> <emeyer> …The first property only makes sense for scrollable overflow<br> <emeyer> …The second would address other things<br> <emeyer> fantasai: None of that invalidates my question<br> <emeyer> iank_: What happens to all the things what you set to none?<br> <florian> q+<br> <emeyer> flackr: What if instead of none, you have a value of clip, which means it's scrollable rect limits to the scrollable area<br> <emeyer> iank_: You might have other things, so I don't think that wil work<br> <emeyer> flackr: Let's say overflow-contribution: none, and you try to scroll to this box that hasn't contributed to scrollable area, but it isn't reachable because the scrollable area hasn't included that<br> <emeyer> iank_: I'm not sure what I would expect to happen there, so a way we could design it is it doesn't produce a snap area<br> <emeyer> …I worry, but the flip side is you might be able to see it because the padding box is big enough to see it, and what happens then?<br> <emeyer> flackr: This is why I was suggesting clipping<br> <khush> q-<br> <emeyer> iank_: I don't think that works but it's a complicated answers based in order of operations on rectangle computation<br> <astearns> ack florian<br> <emeyer> florian: It makes sense as separate properties because you'd want to set them separately at least some of the time<br> <emeyer> …You might want to say "don't show scrollbars" in one place, but in another place you say to snap to where a thing would be<br> <emeyer> …Having one reset the other might work out fine, but I'm not sure<br> <emeyer> …I lean toward separate properties<br> <emeyer> astearns: I'm not hearing consensus on how many properties there should be, so we should go back to the issue because we aren't ready to bikeshed<br> <florian> s/snap to where a thing would be/snap to where a thing would be if it weren't transformed<br> <emeyer> flackr: We should write up the alternatives and use cases so we can figure this out<br> <fantasai> scroll-visibility and transform-overflow?<br> <emeyer> iank_: That sounds fine, so folks can have a think<br> <emeyer> …We have been hearing about this in conversations with devs, so it would be good to address this<br> <fantasai> overflow-ignore: self | transforms | normal<br> <emeyer> …Handling it is pretty easy, so we just need to design it<br> <emeyer> astearns: Agreed<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8361#issuecomment-2166045033 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 15:43:04 UTC