- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Feb 2019 17:38:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Empty grid tracks should contribute to scrollable overflow`, and agreed to the following: * `RESOLVED: Include space in empty explicit grid tracks in the scrollable overflow area` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Empty grid tracks should contribute to scrollable overflow<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3638<br> <dael> astearns: Had some discussion, sounded to me like we were breaking toward including explicit tracks in scrollable area of grid container<br> <dael> fantasai: I agree with that<br> <dael> astearns: Mats had a couple responses at end of thread that sounded like he's not objecting but not happy<br> <dael> fantasai: Wondering if that's b/c impl track info about tracks temp but don't store. Then managing overflow requires tracking additional information somehow. But I think authors really do expect those tracks to be in scrollable overflow so we should do that<br> <dael> astearns: Other opinions?<br> <AmeliaBR> RRSAgent, pointer?<br> <RRSAgent> See https://www.w3.org/2019/02/20-css-irc#T17-17-56<br> <dael> lajava: I also have doubts about impl this in Chrome. I commented some of my issues with this approach. Because the example about grid tracks contributing to intrinisic size I don't think is the ame as contributing to overflow area as Mats pointed out in last comment<br> <dael> florian: You mean technically they're different so no technical reason to handle the same?<br> <dael> lajava: Conceptual PoV. I don't think it's technically difficult but the argument for doing it is tracks contribute to intrinsic size. BUt in this case grid container has a specific size so shoudln't consider tracks as content by themselves. Why the overflow area is bigger then specific size if there is no content?<br> <dael> florian: I think logic is the author explicitly asked for that size. Even if not putting anything in it putting a size indicates theye xpect tht large. The intrinsic size is one way to see that the size they ask is what they get. If they don't observe it as that size it breaks that assumption. yeah there's no content but grid is often to use whitespace as an active part of the design<br> <dael> astearns: If you have a grid container that has explicit grid tracks, is auto sized, and not scrolling you'll see trailing white space before next bit of content. If you then constrain height and make it scrollable that whitespace disappears. That seems surprising to me<br> <dael> lajava: I'm not sure. I think if there are items in the second row even that first is empty I think we use the bottom position of first item to define scrollable area. In a why the whitespaces in the first row are not lost. Youmean the trailing ones? Yeah, I see<br> <dael> lajava: As Mats said there are other ways to achieve that<br> <dael> fantasai: But there's the question of what do authors expect. They expect the rows to be considered as space that'st here. That they're not scrollable is confusing to them and not what expected. If creating a grid and want random empty spots, if they happen to be in one row that row shoudln't collapse away. If theys aid there is a 100px column it should be there. It might be there from impl but end result of the page is you can't tell it's there.<br> <dael> florian: Thought of something else. Invisible things causing scrollbars to appear tends to be a thing authors hate. Given this isn't part of box model this is harder to find. I think with FF grid dev tools you could figure out what's going on but not other browsers<br> <dael> fantasai: I think if you give explicit track sizes you should be able to figure out it's causing the scroll. We also have padding and it should be considered in scrollable and we get a lot of bugs on why it's not. Initial behavior for overflow is you trigger only as necessary to show content. There are a lot of general expecttations that there will be scrollbars<br> <dael> fantasai: Authors are unhappy when don't include padding in scrollable overflow. We're limited by web compat there, but we're not here. I don't think authors will be they put 10 tracks of 100px and why is my scrollable overflow not 500px because only half are full.<br> <dael> florian: I'm back to agreeing<br> <dael> astearns: Your point is fair that this is a new thing that causes space to be added. This isn't in pre-grid dev tools, but that's a dev tool issue<br> <dael> plinss: General principle: If you change the overflow behavior it should not effect it's size<br> <dael> astearns: And size before changed overflow is what we're trying to arrive at where emptytracks contribute to scrollable<br> <dael> iank_: What is use case authors want to have additional tracks?<br> <dael> astearns: Preserving layout intent. It had the whitespace before scrollable so should contibue once it is<br> <dael> florian: And what fantasai said about breathing space between content and edge<br> <dael> iank_: So what padding was previous<br> <dael> AmeliaBR: Or saving space for content that will be added<br> <dael> astearns: Good point. Not changing the size as you add things to explicit grid is pretty useful<br> <dael> iank_: Really good point AmeliaBR<br> <rego> the padding is also lost as oriol explained https://github.com/w3c/csswg-drafts/issues/3638#issuecomment-464400716<br> <dael> astearns: I thinkw e are converging on including explicit grid track sizing to the scrollable area of a grid container<br> <rego> it'll be nice to be consistent on that case in the future too<br> <dael> astearns: Anyone on the call that has an argument against or would object to resolving?<br> <dael> lajava: I think rego has a point with padding not being consistant. I think oriol mentioned that in issue<br> <dael> oriol: Prob with padding is there is no interop. In FF it does not add space but in Chromium the space is always added in block axis and sometimes in inline. So there is no interop. I think this is a similar case and would prefer consistent model.<br> <dael> fantasai: We'd like consistent but we're constrained on compat. There are issues on overflow spec and hte goal is to include the padding.<br> <dael> astearns: If oriol says there is no interop there may be more possibility to get behavior we want<br> <fantasai> See issues in https://drafts.csswg.org/css-overflow-3/#scrollable<br> <dael> fantasai: The amount to which chrome includes padding we're trying to do that. yOu can see those issues on overflow spec. but in inline axis it's pretty random. Sep discussion<br> <dael> daniel: I'm testing chrome 24 and it seems to behave same as FF<br> <dael> lajava: Yes because we just fixed the bug<br> <iank_> s/chrome 24/chrome 74/ (I assume)<br> <dael> lajava: b/c there is nothing in the spec that suggests we should use grid tracks to contribute to overflow area. If we want this to be new we should propose new text<br> <dael> fantasai: Yes, this is not a clarification<br> <dael> astearns: That is a slight concern. There is a bug Chrome canary responded to. I'm not sure if that's interop or if person that wrote the chrome bug wanted space to collapse.<br> <dael> fantasai: Don't know, but guessing spec compliance.<br> <dael> astearns: My guess as well<br> <dael> florian: If I'm looking at right thing, chrome bug is from Mats<br> <dael> lajava: Yeah, original bug was to FF but Mats argued they followed spec and he filed bug against Chrome. WE decided to follow spec<br> <dael> astearns: Thanks for the quick response on that<br> <dael> lajava: Means we need to agree with Mats this is behavior we will impl<br> <dael> astearns: Certainly. If we resolve we need to get Mats to agree to change behavior to spec. Unfortunate he's not on call, but I don't see in his issue comments reasons to not resolve the way we intend<br> <dael> florian: Clarification point or extra argument. Given that Chrome in some cases includes padding if we have empty tracks and padding it seems it will be confusing to including padding and not empty tracks<br> <dael> astearns: Interop on incl padding?<br> <fantasai> https://drafts.csswg.org/css-align-3/#overflow-scroll-position<br> <dael> florian: No but we're trying to including it at least as much as we can. And when alignment is not the default we always do. So when we have some cases where include the padding not including empty track seems weird. Or am I confused?<br> <dael> fantasai: I think we should try and include padding in grid if we can. If we can include empty tracks we should because it's used for many more cases then padding<br> <dael> florian: Yes, but given padding is outside not including the inside is confusing<br> <dael> fantasai: Tackle in sep issue but I think you're right we should adjust grid and flexbox to do thing authors want to do<br> <dael> astearns: Objections to including space in empty explicit grid tracks in the scrollable overflow area?<br> <florian> +1<br> <dael> RESOLVED: Include space in empty explicit grid tracks in the scrollable overflow area<br> <dael> astearns: Hopefully impl can follow. We'll get feedback as we go.<br> <dael> astearns: Do we have issues for including padding in scrollable areas?<br> <dael> florian: We do<br> <dael> fantasai: Might want a separate one on grid<br> <dael> astearns: Is that overflow spec or grid?<br> <dael> fantasai: mmm...I think grid. I'll file<br> <AmeliaBR> Lots of open issues: https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+scrollable+padding<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3638#issuecomment-465680522 using your GitHub account
Received on Wednesday, 20 February 2019 17:38:50 UTC