Skip to content
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

Closed
FremyCompany opened this issue Feb 23, 2018 · 8 comments
Closed

Comments

@FremyCompany
Copy link
Contributor

FremyCompany commented Feb 23, 2018

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:

https://wptest.center/#/677dj4 (CSS Flexbox min-content size seems problematic)
image vs image

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).

In general, the automatic minimum size of a flex item is its specified size if it is defined, or its content size otherwise. However, if the box has an aspect ratio and no specified size, its automatic minimum size is the smaller of its content size and its transferred size. If the box has neither a specified size nor an aspect ratio, its automatic minimum size is the content size.

instead of

In general, the automatic minimum size of a flex item is the smaller of its content size and its specified size. However, if the box has an aspect ratio and no specified size, its automatic minimum size is the smaller of its content size and its transferred size. If the box has neither a specified size nor an aspect ratio, its automatic minimum size is the content size.

@FremyCompany
Copy link
Contributor Author

cc @fantasai @tabatkins @dholbert

@FremyCompany
Copy link
Contributor Author

FremyCompany commented Feb 23, 2018

Another option is to introduce flex-shrink-mode: prescriptive | corrective which defaults to corrective (but defaults to prescriptive if flex-shrink is defined but flex-shrink-mode is omitted?), and acts as a toggle for whether the shrink is considered during the min-content-sizing phase or not.

@dholbert
Copy link
Member

dholbert commented Feb 23, 2018

The pattern we are seeing is authors using <div style="background: url(icon.png); width:32px; height:32px"> in min-content sized/constrained flexboxes

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?

@FremyCompany
Copy link
Contributor Author

@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.

@css-meeting-bot
Copy link
Member

The Working Group just discussed [css-flex] Min-content sizing currently too smart to be web compatible?.

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.

@fantasai
Copy link
Collaborator

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.

@css-meeting-bot
Copy link
Member

The Working Group just discussed Min-content of shrinkable flex items.

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

@css-meeting-bot
Copy link
Member

The Working Group just discussed Min-content sizing currently too smart to be web compatible?, and agreed to the following resolutions:

  • RESOLVED: Accept the proposal
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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants