- From: Lukas Waslowski via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Jan 2025 11:09:09 +0000
- To: public-css-archive@w3.org
> I agree for `progress()`. It takes the same value _types_ and returns the position of the value that sits _**between**_ the two others. ...and because of the _types_ being the same, accidentally mixing up the argument order cannot be discovered statically, but only through observed wrong behavior at runtime (I've got bitten by that while first using `clamp()`, and had to manually split up & debug the expression until I discovered that my assumptions about `clamp()` were wrong). I'd argue for seeing `mix()` as the mirror image/inverse of `progress()` (as `mix(progress(X, A, B), A, B) = X`), and as such should probably have an analogous argument order. --- Due to the prevalence of OOP and it putting the value "being transformed" first (though this also makes sense in functional programming due to currying/partical application), programmers with previous knowledge will probably expect `value,bound,bound`, whether its `value.clamp(bound, bound)` or `clamp(value, bound, bound)`. In my opinion, it would have probably been best for `clamp()` not to differ from the previous art and stay with `value, bound, bound`, but as that is not available: What is the second best option? - Leaving `clamp()` as the odd one out, and making `progress()` and `mix()` consistent with those externally formed expectations. - Favoring internal consistency between `clamp()`, `progress()` and `mix()`, but violating expectations formed by other languages. -- GitHub Notification of comment by cr7pt0gr4ph7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11427#issuecomment-2579865262 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 January 2025 11:09:10 UTC