- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Dec 2017 18:01:56 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `[css-sizing][css-grid][css-flexbox] Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-sizing][css-grid][css-flexbox] Intrinsic Sizes, Scroll Containers, and Grid/Flex Sizing<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1865<br> <dael> Rossen_: fantasai can you take this?<br> <dael> [silence]<br> <dael> fantasai: This was the issue about when you have a flex or grid item andinside it there's really wide content that has scrollbars.<br> <dael> fantasai: When you put this inside a flex item it triggers the impl min siz which looks at min-content size. Usually it's on the smaller size, but for something like this it could be really really big. Bigger then you expect, esp if you have scrollbars in there.<br> <dael> fantasai: But you don't get scrollbars because the ancestor asked for the min size.<br> <dael> fantasai: This is causing a lot of author confusion because some ancestor is making it blow up. THe work arounds are not super objvious.<br> <dael> fantasai: Suggestion when there is an overflow scroll the min-content contribution should be 0.<br> <dael> fantasai: That would prevent this from happening.<br> <dael> fantasai: There are some compat restrictions. For now proposal is: a) don't do this to a block in the block axis and b) don't do it for blocks that have overflow: hidden b/c that's often used to create a flex-root<br> <dael> fantasai: If a box has overflow not visible and not hidden and it's a block in the inline axis its min-content contribution assumes 0. If it's a flex or gird item we do that for any value of overflow that's not visible in both axis<br> <dael> fantasai: We believe this would solve most cases. The fix if it's too small is to apply a min-width which is a fairly understandbale fix.<br> <dael> Rossen_: Thanks fantasai<br> <dael> dbaron: This sounds like a substantial change to existing behavior.<br> <dael> fantasai: Yes.<br> <dael> fantasai: On flex items and grid items prob won't be too surprising. APplying to blocks...if you aheva s crollable block and you're expecting inline size of that block to control the size of its ancestor by sizing so it won't scroll, then your layout would change<br> <dael> fantasai: We can split into two parts, do for grid and flex and can we do for block.<br> <dael> dbaron: If you do it for one but not the other you're changing from one concept of min-content size to 2.<br> <dael> fantasai: Min-content contribution. We already haves pecial behavior for flex and grid when overflow is visible. This is implying the same thing where we don't consider the content for min-content contribution<br> <dael> dbaron: Isn't this non-local? It's arbitrarily deep descendents.<br> <dael> fantasai: No. This is if a paricular element is flex or grid and has overflow not visible we don't look at its content when looking at its own min-content contribution.<br> <dael> fantasai: WE're assuming 0 for the purpose of calc the min-content contribution of that item and this will fix the ancestor issue.<br> <dael> dbaron: Only if the descendent is flex or grid.<br> <dael> fantasai: Yes. That's part 1. Part 2 without would apply to regular block would fix it for block. BUt it's a local problem.<br> <fantasai> s/problem/effect, to fix the action-at-a-distance problem/<br> <dael> dbaron: Seems like you're saying the compat thing only solves half the problem. Given how widely flex and grid are used i"m not sure part 1 is even web compat.<br> <dael> Rossen_: Certainly not for flexbox. I'd be more concerned about that then grid at the moment, but definitely concerned about flexbox.<br> <dael> dbaron: Any sign that impl are not interop?<br> <dael> Rossen_: I don't believe so. fantasai ?<br> <dael> fantasai: I don't believe so either<br> <dael> fantasai: I think the behavior is more in line with what authors expect. When then set it to be scrollable you don't expect it to force the ancestor to give enough space for you not to scroll. I think this would make flex and grid more intutive to authors.<br> <dael> dbaron: I don't think we can change without more evidence it's safe.<br> <dael> fantasai: Fair. I guess we can discuss if we want to change if possible, then we can look and see if it's possible. Not make the change until there's more data.<br> <dael> dbaron: My gut is it's not safe and therefore not worth exploring. Particularly the half change doesn't seem sensible.<br> <dael> fantasai: The thing is the only case...for a block element by itself inside a container you can size it with %. For block elements they're i na flow and they'll take their auto size. The effect in that axis...we don't distinguish between max an dmin content in the block ais. If we try and apply to a block in a block axis we have to introduce this concept and then have the min and max calc differently.<br> <dael> fantasai: The you have a set of blocks and they have a min and a max size and you have to calc layout twice to get the min size.<br> <dael> dbaron: I'm not worried about block axis part. I don't agree with these concepts existin gin the block axis. It's the not doing it for block that's the half chnge.<br> <dael> fantasai: Ideally I'd like to do both, yes.<br> <dbaron> s/for block/for block, just for flex and grid,/<br> <dael> Rossen_: And the second part is a lot scarier meaning doing both would be a lot harder.<br> <dael> Rossen_: This is going to sizing right or flex and grid?<br> <dael> fantasai: sizing<br> <dael> fantasai: In terms of collecting data, that's a project but I'm willing to try and work on it b/c this issue is causing a lot of problems for authors.<br> <dael> Rossen_: Can you point to some of the confusion?<br> <dael> fantasai: There's a bunch of websites trying to explain the fix and the fix isn't obvious.<br> <dael> fantasai: There's a pre several items deep that's causing this and it's not obvious and it's getting exploded. And the explosion is a min-width so even setting a width it won't flex the way you expect.<br> <fantasai> s/width/flex-basis/<br> <dael> Rossen_: Do you want a resolution?<br> <dael> Rossen_: More support to work on it? Sample interest?<br> <dael> fantasai: What I've gotten is we want more data on if it's compat. I'd like to know if the web compat comes back as no problem, would people want to make this change? If the answer is no there's no point in getting data.<br> <dael> Rossen_: As an Edge impl, the impl itself won't be that difficult so if you're probing to see how impl this it, it is fairly doable. But I'm fairly concenred with breakage, I'm sympathetic to dbaron's case.<br> <dael> fantasai: And th epoint is collect data. But if we get data that says it's okay, would you accept the change? If you still don't like the change we've wasted the time to get data. Is it worth it to collect the data?<br> <dael> Rossen_: Okay. If anyone wants to push back on any reason other then interop concerns, this is your chance.<br> <gregwhitworth> https://log.csswg.org/irc.w3.org/css/2017-08-03/#e843776<br> <dael> gregwhitworth: While people think, I want to loop back and say we solved a similar problem for tables. I'll link to the minutes. We hit a similar problem where we have this very scenario.<br> <dael> gregwhitworth: I personally feel there is enough there. I'm not sure if it's worht gathering data. We have compat issues with the inverse.<br> <dael> fantasai: What you're saying is we had an issue with a direct desc of the table which has scroll does not contribute it's min-content. IT was 0.<br> <dael> gregwhitworth: Yeah, it's floored out. THe layout is done and then Chrome fills out. IN Edge we give it the 100% and then the accept term of service ends up offscreen.<br> <dael> fantasai: That's an ex of us having to make for compat reasons the fix being proposed. THis proposal is doing that same kind of fix more generally.<br> <dael> fantasai: Same use cases.<br> <dael> fantasai: Concern for data wasn't if we needed use cases to see if there's author want, this was to see if we can do it without breaking the web.<br> <dael> gregwhitworth: To answer the question better, if there's positive use cases showing people wnat this and you bring back data saying it wouldn't be a problem, I would be shocked if people pushed back.<br> <dael> Rossen_: I also said that impl % resolution for padding was easy for us and it wasn't for others. I'm only speaking for edge.<br> <dael> fantasai: My understanding is becaue it's a local effect it's just a switch on when computing the min-content not to do some extra work. I don't think it's generally difficult to impl.<br> <dael> Rossen_: We're pretty much top of hour. For fantasai to proceed we need to hear there are not strong obj. Most people are worried about interop. gregwhitworth pointed out some issues where peole need the opposite for tables which would bring more arguements against making it for blocks.<br> <dael> fantasai: gregwhitworth 's argument pointed out people are having this behavior for specific tables. It's a point in favor of people expecting the proposed.<br> <dael> Rossen_: Okay.<br> <dael> Rossen_: I'm not hearing any objections. fwiw continue with this.<br> <dael> fantasai: So the conclusion is we expect to accept the proposal if fantasai can get data that's it's webcompat.<br> <dael> Rossen_: Yes. I think going to the step of data is worthwhile.<br> <dael> dbaron: I would hesitate to accept the half proposal, though.<br> <dael> Rossen_: +1 to db<br> <dael> fantasai: We expect to accep thte full proposal if fantasai can get data it's web compat.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1865#issuecomment-351472444 using your GitHub account
Received on Wednesday, 13 December 2017 18:02:06 UTC