[css-typed-om-1] Is it intentional that only existing items in a CSSUnparsedValue can be mutated?

[bzbarsky]

There is an indexed setter, but no indexed creator. So you can mutate the existing list of values, but not extend the list.

(There is also no deleter, but Web IDL no longer supports indexed deleters to start with, so that would be a bit complicated. In an ideal world, though, one could change the length of the list in various ways.)

[tabatkins]

Both of the readwrite indexed things need another pass by me to fill in these details. It's unclear from the WebIDL spec how one is supposed to handle these, and specs disagree in ways that confuse me.

In particular, a lot of indexed-getter/setter interfaces have the getter return a nullable value, presumably with the idea that if you request a non-existent index you get back null. But the behavior of Arrays is to return undefined, and it looks like WebIDL might automatically handle this case for you anyway (if it's not in the list of supported property indexes, your method never gets called at all?).

[bzbarsky]

Your typical nullable-supporting indexed getter looks something like this:

getter Node? item(unsigned long index);

That means it can be invoked as foo[5] or foo.item(5).

When invoked as foo[5] the getter operation is never even called, and undefined is returned, if 5 is out of range.

When invoked as foo.item(5) the operation is explicitly invoked and the fact that it's a getter is not even relevant. It just needs to return whatever type it returns given the input value and it's common to return null on out-of-bounds.

In your case, since your getters are identifier-less, you don't need to worry about the direct call case and can assume you will always be invoked with in-range indices.

[bzbarsky]

In other words, if the getter above were:

getter Node (unsigned long index);

then it could not be invoked other than as foo[5] and would not need the nullability.

[tabatkins]

Ahhhh, that explains some stuff. Thanks!