- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Feb 2020 22:34:58 +0000
- To: public-css-archive@w3.org
You didn't comment further on this, @smfr. Any further thoughts, or do you mind if I just reject these suggestions? --------- Related: it's unclear exactly what "simplify as far as possible" can mean for the case of a min()/max() with *only* percentage arguments, such as `min(10%, 20%)`. We've already established in a previous resolution that, when %s are relative to some other value, you need to wait until they resolve to do any simplification, because in some cases the %s might be relative to a *negative* value and thus `20%` might end up smaller than `10%`. But in some cases we know that the % is relative to a *non-negative* value, so that isn't true, and we *could*, theoretically, immediately resolve `min(10%, 20%)` to `calc(10%)`. However, this (1) seems silly, as it only applies in the (fairly worthless) case of a min()/max() with *only* % values in it, and (2) seems dangerous, as it brings us closer to "percolate arbitrary numeric constraints thru this expression" which I dont' want to do. So I'm planning to make this case clearer in the spec, and mandate explicitly that %s must make the function unresolvable until they resolve against their base value. In particular, this means that an expression like `margin-left: min(10%, 20%)` will serialize as `min(10%, 20%)` in both specified and computed values, and will only simplify away to a single value at used-value time when you can turn those into px values. /cc @xiaochengh @emilio -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4550#issuecomment-589865634 using your GitHub account
Received on Friday, 21 February 2020 22:35:00 UTC