-
Notifications
You must be signed in to change notification settings - Fork 672
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-flex] Min-content sizing currently too smart to be web compatible? #2353
Comments
Another option is to introduce |
There, the icon (i.e. the div) would only shrink if the flex container is skinnier than 32px, right? So, it sounds like the issue is that you're getting is that your "min-content sized/constrained flexbox" is being forced to be too skinny for what its contents really want here. Does the flex container's min-content sizing algorithm produce something less than 32px in this case? If so, maybe that's what we should amend? |
@dholbert that is my proposal indeed. the spec says that you take the minimum of the specified width of the flex item and its content width; since there is no content in the icon div, the content width is 0px and it completely erases the specified width. |
The Working Group just discussed The full IRC log of that discussion<dael> Topic: [css-flex] Min-content sizing currently too smart to be web compatible?<dael> github: https://github.com//issues/2353 <dael> TabAtkins: I need to review this with fantasai <dael> fremy: Then I can introduce it before next week <dael> fremy: We tried to update Edge to folow spec for flex-basis. A lot of websites if you spec width or height even if there isn't content it's respected for min-content sizing. <dael> fremy: We probably don't want ot change this alone or first. Let's discuss next week. |
Tab and I think @dholbert’s explanation in #2353 (comment) makes the most sense as a way to address this, so we've drawn up some edits for it, see https://drafts.csswg.org/css-flexbox-1/#change-2017-flex-min-contribution @dholbert @FremyCompany Please let us know if this seems like a good way to solve the problem. We'll also be running it past the CSSWG shortly to confirm with them as well. |
The Working Group just discussed The full IRC log of that discussion<dael> Topic: Min-content of shrinkable flex items<dael> github: https://github.com//issues/2353 <dael> TabAtkins: We made some edits and we need to WG to approve. <dael> Rossen: Can you go over the edits? <fantasai> https://drafts.csswg.org/css-flexbox-1/#change-2017-flex-min-contribution <dael> TabAtkins: Last comment in the issue has a link to the change <dael> fremy: I need to process it. <dael> astearns: Anyone else want a summary? <dael> Rossen: Let's get back tomorrow. I want to look as well b/c I spent time working on this issue. We had a change fixing some edge inconsistencies with this problem. We have to back it out because it seemed others were inconsistant. <dael> fantasai: We went with dholbert's solution over fremy. <dael> astearns: There's a 2nd layout section Thursday morning. Let's add this then |
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: Min-content sizing currently too smart to be web compatible?<dael> github: https://github.com//issues/2353 <dael> fremy: The issue was that...min-content by default when you can shrink could shrink to the min-content. Web expected width as well. I reviewed the change and it seems right, but the summary was missing details. <dael> fremy: Still means you have elements that could shrink further but will not. I'm fine with the change how written. <dael> Rossen: What's the summary? <dael> fantasai: We made the min-content contribution of the flex item consider width and height. <dael> ??: Does it match what min-width auto computes to? <dael> fremy: Spec changed the minimum size all the time. Width works anyway. <Rossen> s/??/biesinger/ <dael> fantasai: Because if we change how min-width auto works it would change how ti shrinks down <Rossen> s/biesinger/cbiesinger/ <dael> fantasai: We had to do it through the min-content contribute tion through auto because the web depends on it. <dael> Rossen: Prop resolution is accept this change? <dael> fremy: The width and heigh property does effect min-content contribution, right? <dael> fantasai: Yeah. <dael> cbiesinger: We don't impl min0size contribution per spec. Does anyone? <dael> Rossen: We're close. We had reworking recently and since we were close to shipping we had to pull back due to unexpected side effects. This is part of the changes. <dael> Rossen: So, kind of. <dael> cbiesinger: You find it web compat? <dael> fremy: We won't know unitl we do this fix and try again. <dael> cbiesinger: Can you prioritize? <dael> Rossen: Yes fingers cross. <dael> Rossen: Obj? <cbiesinger> s/min0size contribution/intrinsic size computation/ <cbiesinger> s/Can yoy/I should/ <dael> RESOLVED: Accept the proposal |
Hi css-flexers from all around the world,
I just wanted to report that our attempt to update our flex implementation sizing algorithm to match the spec encountered a few hiccups, but this one seems like the most concerning so far:
The pattern we are seeing is authors using
<div style="background: url(icon.png); width:32px; height:32px">
in min-content sized/constrained flexboxes, and the icon ends up disappearing because flex-shrink defaults to 1 by default.I think we should update the specification such that an explicit width acts as a minimum width (even though it could theorically be shrunk).
instead of
The text was updated successfully, but these errors were encountered: