- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Mar 2023 00:36:20 +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`, and agreed to the following: * `RESOLVED: Adopt this feature as overflow-bikeshed` <details><summary>The full IRC log of that discussion</summary> <fantasai> See also leaverou's examples in https://github.com/w3c/csswg-drafts/issues/8400<br> <dael> TabAtkins: Happy to take it since raised by non-WG and leaverou is not available<br> <dael> TabAtkins: Request is some way of opting an element out of contributing to ancestor scrollable overflow. Lots of examples of places with decorative element that happens to overflow and element a little bit. Overflow isn't important. Stuff in viewport is important but you trigger scrollbars<br> <dael> TabAtkins: Example from leaverou is the fork me banner on GH that's at 45 deg angle and has a little corner poke out. Another example is animating an element into the page it's outside the page as it animates in, triggers scrollbars, but once it's in place no scrollbars.<br> <iank_> q+<br> <dael> TabAtkins: Forcing an element to only contribue ink overflow. More to discuss about using it in a safe fasion, but use case is worth addressing and should explore in overflow 4<br> <Rossen_> ack iank_<br> <dael> iank_: Trivial for implementation, more or less what we do for position:fixed already. Want to make sure this doesn't effect the content-edge contribution to scrollable overflow. I don't think that breaks any use cases<br> <dael> iank_: If you have element in block flow at the end the end content edge contributes to scrollable overflow, but when you rotate the element wouldn't. Want to make sure of that. Otherwise, this would be great<br> <dael> TabAtkins: More details on the case?<br> <dael> iank_: Maybe grid is easier to explain. The content-edge- we add the end content edge; padding after content edge; as scrollable overflow. To do taht look at where children are or look at grid itself. Grid, see last row and column, add end padding, and that's part of scrollable overflow<br> <dael> iank_: If we start excluding things from the content-edge calc it gets tricky very quickly<br> <dael> TabAtkins: Do we currently pay attention to things like box shadow for that calc?<br> <dael> fantasai: No b/c ink overflow<br> <dael> TabAtkins: Assume similar here<br> <dael> fantasai: I think iank_ is saying there are things not descendant boxes that are for scrollable overflow and we shoudln't change that?<br> <dael> iank_: Correct. When calc overflow we factor in a bnch of things like where the padding is. Don't want to effect that calculation<br> <dael> fantasai: I agree and I don't think that's requested. Need to set on the element containing the padding. You'd like to set on an element whose ancestor is a scrollable<br> <dael> iank_: A bit of a nuance b/c could say you shouldn't include me where the content edge is but want the distinction<br> <dael> fantasai: I think if we add it's a property on an element you want to exclude that says ignore me when calc scrollable overflow<br> <dael> fantasai: Might want a distinction between ignore my box but pay attention to my contents vs ignore me and all my contents. I can imagine a rotated box with padding where you don't care about corners but you do want the text scrollable<br> <dael> fantasai: Prop 3 values, One is normal, one is ignore my box, one is ignore me and all my descendants<br> <dael> TabAtkins: Makes sense<br> <dael> iank_: Want to check with authors on more complex. It sounds fine<br> <flackr> Sounds reasonable. Could allow setting the not ignored property on a descendant for some of those descendant cases<br> <dael> Rossen_: Clarification - assuming this is true for my immediate scrollport ancestor and all of it's ancestors? Including initial?<br> <dael> TabAtkins: Yep. Ideal is you markt he element as ink overflow so it's the same as ink overflow in all scrollers<br> <dael> TabAtkins: iank_ hypotheitical. Animating element up from bottom to visible. I have this marked on it. Do you think okay or would it make scrollbars?<br> <dael> iank_: If it's out of flow positioned behaves as you expect. If it's in flow you would still consider end content edge<br> <dael> TabAtkins: That sounds good. We'll have to make sure we get that b/c it's a little more nuanced, but I think it's fine. Will need to word carefully.<br> <Rossen_> q?<br> <Zakim> fantasai, you wanted to ask about element vs descendant content<br> <dael> iank_: fwiw if we can come up with a reasonable syntax this is trivial to impl<br> <dael> fantasai: Name is had. overflow-skip?<br> <fantasai> s/had/hard/<br> <dael> TabAtkins: We can do names in the thread<br> <dael> Rossen_: Overall sentiment is we want to resolve on adopting the feature and figure out name as we go. Anything else to talk about or resolve on this?<br> <dael> TabAtkins: That's all<br> <dael> Rossen_: Obj on Adopt this feature as overflow-bikeshed<br> <dael> RESOLVED: Adopt this feature as overflow-bikeshed<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-1451097120 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 March 2023 00:36:22 UTC