- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Dec 2023 12:19:37 +0000
- To: public-css-archive@w3.org
> That's pretty fragile, and it means that `round(var(--foo))` may or may not be valid That's true in any case, as `--foo` can hold anything. Though we could also define that the unit of the first operand is used. So `round(3.14159em + 2.71828em)` = `round(3.14159em + 2.71828em, 1em)` = `6em`, `round(1em + 10px)` = `round(1em + 10px, 1em)` = `2em`, and `round(10px + 1em)` = `round(10px + 1em, 1px)` = `26px` (in case `1em` = `16px`). That makes it explainable and less fragile. > and might round to an unpredictable precision, based on how the value is written somewhere else. The precision is not unpredictable, it is unit-based. > Similarly, rounding to the nearest degree doesn't seem particularly useful for most cases. The canonical unit is quite arbitrary, and generally speaking I don't think people will commonly be rounding to 1 of _any_ unit. The point is to provide a reasonable fallback / default. Authors will still be advised to provide a rounding interval if they want to influence the rounding precision. > Another viable solution I see would be to treat a `<number>` given as the second parameter not as a module but as the number of decimal places. Note that Firefox already ships the `round()` function. So, a change in behavior will break any current usages. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9668#issuecomment-1847077937 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 8 December 2023 12:19:40 UTC