- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Aug 2024 06:04:47 +0000
- To: public-css-archive@w3.org
> No, both of those act the same whether you use the argument as written or properly resolve it first. Agreed for `abs()`, but the result of `sign(1%)` can be `-1`, the result of `sign(1em)` can be `0`, and so on. However, returning the sign of the unresolved value would be useless. So, ok. > They're not valid. I misinterpreted *"a calculation which must resolve to a `<number>`"* (or `<angle>`) in the definition of all these functions. As hinted by your comment, this applies to the calculation type, not its value. That is, the calculation type must [match](https://drafts.css-houdini.org/css-typed-om-1/#cssnumericvalue-match) `<number>`. I do not want to be picky if the current wording is unambiguous. The thing is that there are many examples across the specs that define how a percentage *resolves* to a number or dimension. But I also realized that allowing `<percentage>` (value) resolving to `<number>` would implicitly require allowing `<percentage>` and `<number>` to be combined, otherwise `pow(1%, 1)` would otherwise be invalid anyway. --- I would be grateful if you could give me an example of a definitely-invalid calculation that would appear possibly-valid when allowing `<percentage>` to resolve to `<number>`. -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10765#issuecomment-2306355058 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 August 2024 06:04:48 UTC