You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-sizing] Aspect-ratio min-size needs to check for "auto", not non-zero #4217
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.)
@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.
@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?
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>).
Activity
[css-sizing-3] Remove non-zero to avoid open-range problem. (Initial …
fantasai commentedon Dec 12, 2019
Checked for
definitegenerally, sincemin-contentand percentages are non-auto but still problematic. Lmk if that seems correct.CC @Loirooriol for sanity-checking :)
Loirooriol commentedon Dec 13, 2019
@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
autominimum size resolves to a definite0.fantasai commentedon Aug 11, 2020
It's currently specced as
if the box has a [=definite=] non-''min-width/auto'' value, thanks to ce03a20 ...[css-sizing-3] Use <<length>> rather than definite to avoid complexit…
tabatkins commentedon Aug 11, 2020
@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 commentedon Aug 23, 2020
Checking for a computed
<length>seems a bit strange to me, because100%is a<percentage>, butcalc(100% + 100px)is a<length>when used inmin-widthif I get https://drafts.csswg.org/css-values-4/#determine-the-type-of-a-calculation right?tabatkins commentedon Oct 13, 2020
Not quite! Following the definitions, the type of
100% + 100pxis 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 commentedon Oct 13, 2020
@Loirooriol So, with that explanation, does the spec seem okay?
Loirooriol commentedon Oct 13, 2020
Yes, then it looks good to me
[css-sizing-3] Use <<length>> rather than definite to avoid complexit…