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-sizing] Aspect-ratio min-size needs to check for "auto", not non-zero #4217

Closed
tabatkins opened this issue Aug 19, 2019 · 8 comments
Closed
Labels
Closed Accepted by Editor Discretion Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-sizing-3 Current Work

Comments

@tabatkins
Copy link
Member

In https://drafts.csswg.org/css-sizing-3/#intrinsic:

Otherwise if the box has a definite non-zero min-width or min-height, use that size and calculate the other dimension using the aspect ratio; if both dimensions have a definite minimum, choose the one that results in the larger overall size.

This should probably be checking for non-"auto", not non-zero. (Open ranges are bad.)

@tabatkins tabatkins added the css-sizing-3 Current Work label Aug 19, 2019
fantasai added a commit that referenced this issue Dec 12, 2019
…value is 'auto', so this won't shrink down to zero by default.) #4217
@fantasai
Copy link
Collaborator

Checked for definite generally, since min-content and percentages are non-auto but still problematic. Lmk if that seems correct.

CC @Loirooriol for sanity-checking :)

@Loirooriol
Copy link
Contributor

@fantasai I think that could clarify that the value to be checked for definiteness is the computed value, not the used value, since in most cases an auto minimum size resolves to a definite 0.

@fantasai
Copy link
Collaborator

fantasai commented Aug 11, 2020

It's currently specced as if the box has a [=definite=] non-''min-width/auto'' value, thanks to ce03a20 ...

fantasai added a commit that referenced this issue Aug 11, 2020
@tabatkins
Copy link
Member Author

@Loirooriol We went ahead and simplified it further, to explicitly check for a computed <length>. Since this isn't matching impls or anything, just trying to make a slightly smarter default than 300x150, we figure that's probably okay. This work for you?

@Loirooriol
Copy link
Contributor

Checking for a computed <length> seems a bit strange to me, because 100% is a <percentage>, but calc(100% + 100px) is a <length> when used in min-width if I get https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation right?

@tabatkins
Copy link
Member Author

Not quite! Following the definitions, the type of 100% + 100px is obtained by adding the types of 100% and 100px; following that link to TypedOM, we find that the resulting type is "length, with a percent hint set to length".

Then, a calc() matches a production if its type matches that production; following the link again to TypedOM, a type with a percent hint can not match <length> (because it contains a non-resolved percentage that we're inferring to be compatible with <length>).

@tabatkins
Copy link
Member Author

@Loirooriol So, with that explanation, does the spec seem okay?

@Loirooriol
Copy link
Contributor

Yes, then it looks good to me

@Loirooriol Loirooriol added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Commenter Response Pending labels Oct 13, 2020
kevers-google pushed a commit to kevers-google/csswg-drafts that referenced this issue Jun 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by Editor Discretion Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-sizing-3 Current Work
Projects
None yet
Development

No branches or pull requests

3 participants