- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Mar 2018 16:42:45 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229`, and agreed to the following resolutions: * `RESOLVED: overflow:clip is a paint time only operation and we shouldn't require that an element with overflow as clip in either direction be a BFC nor a scroll port.` <details><summary>The full IRC log of that discussion</summary> <dael> topic: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-370692229<br> <dael> Rossen_: florian sent regrets. can someone else take it?<br> <dael> fantasai: There's several issues here. Main one is that we wanted to figure out what various values of overflow compute to when you set...set x axis but not y.<br> <dael> fantasai: Before we introduced clip any value that's not visible in one axis causes the other axis compute to auto so you have a scroll container in both axes.<br> <dael> fantasai: Clip didn't spec how to compute. In general it was supposed to not trigger a scroll container.<br> <dael> fantasai: Combo of clip in one axis and visible in the other seems to be valid and should not cause visible to compute to auto<br> <fantasai> https://github.com/w3c/csswg-drafts/commit/1d1a8e9caf4333518620e32f2a8b08ec3efdfa13<br> <dael> fantasai: We updated computed value field. That's the first request. Current text says if one axis is not visible or clip then any axis that's visible or clip computes to atuo or hidden<br> <dael> fantasai: Changeset^<br> <dael> fantasai: That raised the question of but clip creates a BFC and visible doesn't, what happens when it's overflow:visible in one axis and clip in the other. That caused a sep discussion on if a BFC.<br> <dael> Rossen_: WE should take these one at a time. Thought they're related I think we can resolve independantly.<br> <dael> dbaron: Bigger issue is should clip create BFC and the other thing falls out.<br> <dael> Rossen_: Correct. fwiw I think we had this discussion in the past and every time we do a full circle and at the end we convince ourselves that not having it be a BFC becomes complex for implementation.<br> <dael> Rossen_: At least what I recall is are how floats that start before the element with a clip and extend past the clip region, how are they effected in terms of flow.<br> <dael> Rossen_: If clip is intended to be render time only effect...nevermind.<br> <dael> Rossen_: The interaction between floats that start before clipping elements or those on the side are hairy if overflow:clip is not BFC. If it is BFC it's predicatble but then you have overflowing visibly content to the lefft or right and because BFCs allow floats next to them you have overlapping content with floats.<br> <dbaron> I didn't actually follow that... and I actually don't remember having this discussion before.<br> <dael> Rossen_: Every time we have this discussion I recall us coming back to the BFC one makes the most sense if we have to impl.<br> <dael> Rossen_: I'm happy to discuss one more time if people think we can arrive at a different resolution.<br> <dael> TabAtkins: I think it's clear if there's a bfc creating context it's scroll. For clip it's just a matter of what hte intent of the value is. If as dbaron says clip is supposed to be like visible but without painting outside the bounds that's fine. Geometry will project out but it does what we're asking for here.<br> <dael> TabAtkins: If we want to restirct geometry clip is hidden with 0 ability to scroll. We have to decide.<br> <dael> fantasai: Or we make it effect alyout by truncating the float.<br> <dael> TabAtkins: That's a new concept that I'd prefer not to add.<br> <AmeliaBR> Floats affecting layout outside of the container but not painting outside the container sounds super confusing.<br> <dael> dbaron: The two things we described extend existing concepts and don't require huge changes. If we create one of those concepts we may decide to make the other in the future so we should name appropraitely.<br> <dael> TabAtkins: IN that case, on naming issue, perhaps we can plan for visible-clip and hidden-clip to suggest they're same as base...wait...doesn't make sense.<br> <dael> Rossen_: What was the motivation use case here?<br> <dael> TabAtkins: I presume dbaron can explain the visible unscrollable<br> <dael> dbaron: It's what css2.0 spec. The hidden creating a scroll container and bfc was new to 2.1. It's what the WG rec recommended for a decade.<br> <dael> Rossen_: and you're only impl?<br> <dael> dbaron: I think so. Other impl did hidden in terms of scrolling.<br> <dael> Rossen_: If this is back compat with not compat reature should we decide?<br> <dael> dbaron: I don't think that's why it was added to spec.<br> <dael> Rossen_: Was it used anywhere?<br> <dael> dbaron: Internally. not externally.<br> <dael> fantasai: I think idea was to not have some of the hidden side effects like a scroll container.<br> <dael> fantasai: Has a bit more effect on stuff now then in the past. In the past it meant you have slightly different perf considerations. Sometimes certain user events can scroll a hidden thing. Currently if you turn something into a scroll container it catches things like scroll snap<br> <dael> Rossen_: This is a large topic. I think this is perfect for whiteboard between sessions thing and convince ourselves one way or another. And then hopefully we have florian. Should we table?<br> <dael> TabAtkins: I'm fine right now resolving clip is the visible but doesn't paint outside the bounds thing. I can see use cases for it as fantasai describes. Doesn't disturb margin or capture scroll snaps.<br> <dael> Rossen_: Margin collapsing and everything else?<br> <dael> TabAtkins: Same as visibility.<br> <dael> Rossen_: Visibility:hidden takes layout space.<br> <dael> TabAtkins: This will too<br> <dael> Rossen_: No, it says you stop at the bounds of your container. Which means if you have a whole bunch of floats or 0 height divs with negative margins that effect after clip but they're overflowing, do you take that into account?<br> <dael> TabAtkins: I'm not willing to spec something that clips geometry. I'd be happy with the it's like visible buy clips paining<br> <dael> Rossen_: If you don't have floats and a div with overflow-clip:veritical and a bunc hof text with at the end a div with a huge negative bottom margin. It overflows.<br> <dael> Rossen_: After the clip the div isn't visible nor is the content. Is the negative margin in effect?<br> <dael> TabAtkins: Full geometry. Exactly like visibility:hidden but you extend the geometry<br> <dael> dbaron: I'm not sure visibility:hidden is greatest analogy, but it's purely a paint time effect. Layout is the same as overflow:visible but descendors outside bounds are clipped<br> <dael> frremy: We haave requests for overflow:hidden but have position sticky work and I think this fixes that.<br> <dael> TabAtkins: That's good. Another thing scroll containers block. Nice use case.<br> <dael> TabAtkins: I'm seeing good reasoning for a purely paint time clipping. You'll have weird looking stuff sometimes, but that's going to be rare. If you don't want that use overflow:hidden<br> <dael> Rossen_: And we shouldn't ask people to do that with clip or clip path? How many other ways do we have for clipping?<br> <dael> Rossen_: This was the intent of css clip in 2.1<br> <dael> TabAtkins: Good point.<br> <dael> dbaron: Clip in 2.1 was only for abspos. We can't change that due to compat.<br> <dael> Rossen_: I don't think we can undo the things in the past. What we can do is narrow down this issue and see if we can get consensus<br> <dael> Rossen_: Sounds like most people feel like overflow:cip is a paint time only operation and we shouldn't require that a element with overflow as clip in either direction be a BFC. The note in the spec would be yes geometry and everything else works as it does before and if geometry overflow it will have side effects.<br> <fantasai> +1<br> <dael> Rossen_: Would people object to this as a resolution?<br> <dael> RESOLVED: overflow:clip is a paint time only operation and we shouldn't require that an element with overflow as clip in either direction be a BFC nor a scroll port.<br> <TabAtkins> Yeah, not seeing why we shouldn't just use clip-path here. Need to recall what the syntax is of just clipping to border box.<br> <dael> Rossen_: Now if overflow computes to clip in one direction or visible in the other. If we have overflow...I'm confused if we need a resolution. If you have overflow auto or scroll in one direction the other is hidden by default. If you have clip in one direction the other is visible.<br> <dael> TabAtkins: We need a resolution because we have termonoloy that talks about this.<br> <dael> Rossen_: What would you want to call this?<br> <dael> TabAtkins: Dunno<br> <dael> fantasai: I'm confused that we need. If we have the reoslution we need to resolve on the changes in the issue.<br> <dael> TabAtkins: We have various specs that have behavior when overflow is non-visible, but it means when it causes a scroll container. So clip now falls into visible so we need specs to refer to a term.<br> <dael> Rossen_: Can we replace to overflow computes to scrollable or non-scrollable?<br> <dael> fantasai: It's editorial. We don't need a resolution.<br> <dael> TabAtkins: Yeah. But we need to do it.<br> <dael> Rossen_: No more resolutions needed and we can move on?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1971#issuecomment-376954202 using your GitHub account
Received on Wednesday, 28 March 2018 16:42:48 UTC