- From: Christoph Päper via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Dec 2023 08:37:12 +0000
- To: public-css-archive@w3.org
I agree with @SebastianZ and @Loirooriol that it would be *unintuitive* for authors if the rounding base defaulted to `1<canonical unit>`, especially for simple terms like `2.3em`, but it might still be the most *reasonable and useful* solution, because you hardly ever round simple terms. You usually need either the result of a calculation rounded with the resulting unit or a value with a relative unit, e.g. `em` or `%`, expressed as an integer amount in an absolute unit like `px`. My educated guess is that the most common use case by far will be rounding (calculated) lengths to whole pixels. Since `px` is the canonical unit there, this would be covered nicely. 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. Then, `round(4.32, 1)` would compute to `4.3` instead of `4` and likewise `round(4.32em, 1)` = `4.3em`, while `round(4.32em, 1em)` would yield `4em`. The default value would be `0`. Finally, instead of defaulting to `1`, `1<resulting unit>` or `1<canonical unit>`, the second parameter could support keywords: * `round(4.32em, auto)` = `4em` * `round(4.32em, default)` = e.g. `69px` * `round(4.32em, none)` = e.g. `69.12px` -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9668#issuecomment-1844896648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 December 2023 08:37:15 UTC