- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Nov 2024 09:49:01 +0000
- To: public-css-archive@w3.org
cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts-4] How to handle math functions in font feature value declarations? == The value of a [font feature value declaration](https://drafts.csswg.org/css-fonts-4/#font-feature-value-declaration) is internally stored and exposed as unsigned integer(s) ([spec](https://drafts.csswg.org/css-fonts-4/#cssfontfeaturevaluesmap)). But math functions are accepted in any context, unless otherwise specified, and are resolved at computed value time or later. So what is the expected output below? ```js const sheet = new CSSStyleSheet sheet.insertRule(` @font-feature-values name { @annotation { boxed: calc(1em / 1em); } } `) sheet.cssRules[0].annotation.get('boxed'); // ??? ``` I see 3 options: 1. `[]`: disallow math functions in font feature value declarations (by defining them with `<number-token>` whose type should be `integer`, instead of `<integer>`) 2. `[1]`: resolve math functions at parse time in font feature value declarations (assuming relative length can be resolved, [#10853](https://github.com/w3c/csswg-drafts/issues/10853)) 3. `calc(1em / 1em)`: deal with `CSSOMString`s instead of `unsigned long`s I have a preference for 3. Even if math functions might not be useful in this context, 1 is restrictive and 2 is static. Besides, with [`@view-transition/types`](https://drafts.csswg.org/css-view-transitions-2/#dom-cssviewtransitionrule-types), they are the only descriptors whose attribute getter do not return a `CSSOMString`. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11261 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 November 2024 09:49:02 UTC