Re: [csswg-drafts] [css-values] Let B default to 1 in `round(<strategy>?, A, B)` (#9668)

> 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