Re: [csswg-drafts] [css-values-4] Specify simplification of min() and max() more explicitly (#4550)

The CSS Working Group just discussed `[css-values-4] Specify simplification of min() and max() more explicitly`, and agreed to the following:

* `RESOLVED: min and max get simplified by simple unit values of the same unit we reduce to one instance of each. We also reorder the arguments in the same way that sums reorder. Review math functions for consistency`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-values-4] Specify simplification of min() and max() more explicitly<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4550<br>
&lt;dael> TabAtkins: Important question is with a min and max funct the spec declares we simplify arg as much as possible and when can fully resolve we replace function with results<br>
&lt;dael> TabAtkins: emilio and smfr wanted to partly implify. Example min(10px,20px,1em) we simplify eagerly to eliminate 20px because there's no way that can be a result. 1em is unclear but when arguements are same unit you can simplify eagerly<br>
&lt;dael> TabAtkins: Do we want to do that is the question<br>
&lt;dael> TabAtkins: IN general I've held only simplify if can befully gotten ride of. But I do simplify sums so ameniable to this level of simplification. not futher. If no objections I'm happy to go ahead and do what emilio wants and allow same unit simple values to be removed from min or max when clearly superfluous.<br>
&lt;dael> TabAtkins: If no obj I'll do that bit and mo more<br>
&lt;TabAtkins> s/ mo / no /<br>
&lt;dael> heycam: For em units it's reasonable to assume non-negative. Case for %?<br>
&lt;emilio> TabAtkins: If we do that we also probably want to define _some_ ordering for those factors (probably the same as for products and sums)<br>
&lt;emilio> Because to simplify fast you want to sort first<br>
&lt;dael> TabAtkins: Depending on property % can be postive or negative or positive only. Can't tell before resolved so need to leave. DOn't want to distinguish cases about when % is against non-negative becuase seems more complex then needed here. Would rather % stay always because there are cases where they can be resolved negative<br>
&lt;dael> heycam: Agree. Technically with 3 % you can get rid of one<br>
&lt;dael> TabAtkins: Yeah but don't want to go to that level<br>
&lt;dael> astearns: emilio comment on IRC<br>
&lt;dael> TabAtkins: He argues we should order factors. Sums serialize in an order. emilio argues to do same for min and max where we eagerly sort arguments.<br>
&lt;dael> TabAtkins: That's fine, we can do that<br>
&lt;dael> TabAtkins: Makes sense since they're binary. If we're doing some simplification I'm fine with that case<br>
&lt;dael> astearns: Other comments?<br>
&lt;TabAtkins> s/they're binary/min and max are equivalent to sum and product/<br>
&lt;dael> smfr: Fine with this. Wanted similarity. Want to look at other math functions coming up to see if need consistency<br>
&lt;oriol> I'm having sound problems. I think this may add more confusion than anything<br>
&lt;oriol> And not much consistent to do it for min/max but not for hypot<br>
&lt;dael> TabAtkins: Other then hypot I don't think anything else. I don't think I want to inter-arg simplify hypot. Step too far.<br>
&lt;dael> TabAtkins: If we have more functions that are commutative binary we should do same thing. Nothing outside min and max fit the bill so far<br>
&lt;dael> astearns: oriol has sound problems but shoulds like agrees to do it as hypot. Think it may cause more confusion<br>
&lt;oriol> I think functions are different than sums because sums are an operator<br>
&lt;oriol> So that argument doesn't convince me<br>
&lt;dael> TabAtkins: Lots of simplification is arbitrary line of where we do it. Saying it's exactly like plus is a fine boundary. Happy to do it with min and max and make that the boundary. If it's essentially plus you simplify. If not you only do it when you can simplify the entire thing away<br>
&lt;oriol> It's even implicit in the notation, + is the usual notation for a commutative group structure in mathematics. It's less clear in min() or max()<br>
&lt;dael> astearns: oriol would you object to the simplifications?<br>
&lt;TabAtkins> min/max are associate+commutative in the same way that + and * are<br>
&lt;TabAtkins> nothing else (including hypot) is<br>
&lt;dael> astearns: TabAtkins can you summarize?<br>
&lt;dael> TabAtkins: Prop: min and max get simplified by simple unit values of the same unit we reduce to one instance of each. We also reorder the arguements in the same way that sums reorder<br>
&lt;oriol> I don't object, but I think this may just add more confusion for authors, so I would prefer to treat functions as black boxes until we have resolved all arguments and can actually call them<br>
&lt;dael> dholbert: Question on that. Is it possible for % to resolve to a negative?<br>
&lt;dael> TabAtkins: Yeah.<br>
&lt;dael> dholbert: So min(2%) isn't resolvable<br>
&lt;dael> TabAtkins: Yeah, we exclude % from that<br>
&lt;dholbert> s/min(2%)/min of two percent values/<br>
&lt;dael> astearns: Also we will look through math functions and make things consistent<br>
&lt;dael> astearns: oriol doens't object, just doesn't think it's useful.<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: min and max get simplified by simple unit values of the same unit we reduce to one instance of each. We also reorder the arguments in the same way that sums reorder. Review math functions for consistency<br>
&lt;dael> astearns: oriol please continue discussing in the issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4550#issuecomment-594970559 using your GitHub account

Received on Thursday, 5 March 2020 00:54:11 UTC