- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Oct 2022 07:32:16 +0000
- To: public-css-archive@w3.org
> I don't have a strong opinion on whether we clamp or not here, but I lean weakly towards "don't clamp" for the same reasons @nt1m gave. It seems to me "unclamped" would still leave it undefined whether `calc()` expressions should be only simplified but left there literally, or evaluated/computed and then left unclamped. FWIW, leaving things unclamped or having to return csstext as specified literally would prevent the implementation from storing specified values in a more pre-computed, more efficient or canonical way. Instead the implementation would need to keep a backup of the original css text which may not be identical to what it's using internally. The as-specified text/values do not need to be stored, as there is no need to re-compute values after cascading. I tend to think, keeping only a evaluated and simplified form seems to be the better choice: - If a descriptor is specified twice, we would already simplify towards returning only one value when accessing the serialized value. - Similarly, the serialization of `@font-palette-values` and `@font-feature-values` is also underspe'ed, which we may want to fix at the same time. In particular in `@font-feature-values`, there are many examples of how values can be overridden, or redundantly specified (Examples 60 and 61 of https://www.w3.org/TR/css-fonts-4/#font-feature-values-syntax) - Here, it would be very cumbersome to store the original form instead of a canonical form with only the actively used values. - In issue #7925 we're discussing the simplification of 0 sized ranges for `font-weight`, `font-stretch`, `font-style` ranges and the proposal to collapse these into a single value seems to have received support there. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7964#issuecomment-1294589387 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 28 October 2022 07:32:18 UTC