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

[cdoublev]

Follow-up on this comment.

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 a negative value is converted to the maximum allowed value when converted to an unsigned value. (edit: this is the behavior observed in webidl2js but I think it is correct)

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:

@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 values against the grammar of featureValueName. If it fails, throw a SyntaxError exception.