[csswg-drafts] [css-fonts-4] Should `CSSFontFeatureValuesMap.set()` take signed values? (#11158)

cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts-4] Should `CSSFontFeatureValuesMap.set()` take signed values? ==
Follow-up on this [comment](https://github.com/w3c/csswg-drafts/issues/9926#issuecomment-2017241274).

[`CSSFontFeatureValuesMap.set()`](https://drafts.csswg.org/css-fonts-4/#dom-cssfontfeaturevaluesmap-set) currently takes unsigned value(s):

```
interface CSSFontFeatureValuesMap {
  maplike<CSSOMString, sequence<unsigned long>>;
  undefined set(CSSOMString featureValueName, (unsigned long or sequence<unsigned long>) values);
};
```

But `unsigned long` are [converted](https://webidl.spec.whatwg.org/#js-unsigned-long) to the maximum allowed value.

I see different options:

  1. accept negative values (only in the setter) but throw an exception
  2. normalize negative values to `0` (current behavior in Chrome)
  3. no change

There is currently no related test on WPT.

I prefer 1 because it is consistent with how negative values are handled in a style sheet:

```css
@font-feature-values name {
  @annotation {
    boxed: -1; /* <- invalid and ignored */
  }
}
```

Instead of:

  > The method throws an exception if an invalid number of values is passed in. If the associated feature value block only allows a limited number of values, the set method throws an `InvalidAccessError` exception when the input sequence to set contains more than the limited number of values.

The setter definition could just be:

  > [Parse](https://drafts.csswg.org/css-syntax-3/#css-parse-something-according-to-a-css-grammar) `values` against the grammar of `featureValueName`. If it fails, throw a `SyntaxError` exception.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11158 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 November 2024 10:05:48 UTC