[css-houdini-drafts] [css-typed-om] Switch CSSUnparsedValue and CSSTransformValue to having an arrayish member? (#948)

tabatkins has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [css-typed-om] Switch CSSUnparsedValue and CSSTransformValue to having an arrayish member? ==
Background:
After continually running into walls with getting better WebIDL support for array-likes, I gave up and designed CSSTransformValue and CSSUnparsedValue to use the family of existing WebIDL features that make something vaguely array-like (indexed getter/setter/creator, iterator, magic length, etc).  

(CSSNumericArray is similar, but on a close look, appears to be an evolutionary spandrel. I've filed #947 about that.)

-------

In <https://github.com/heycam/webidl/issues/796>, @domenic is figuring out how to add array-likes to WebIDL. They've got two complementary approaches:

1. Creating two Array subclasses (for user-mutatable and not) in WebIDL, and letting interfaces `extends` from them to get all the good behavior (magic `.length`, all the array methods, returning true from `isArray()`, etc)
2. Creating an `arraylike<Foo>;` declaration, a la `maplike<>;`, that an interface can declare that'll do *most* of the good behavior.

I get the *feeling* that 1 is kinda better than 2, and should be preferred when possible. We might be able to change CSSUnparsedValue and CSSTransformValue to do this, having a member that's a typechecked array, once those are finished being invented.

@domenic, is this feeling correct? Or would it be okay to leave them as-is?

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

Received on Tuesday, 17 September 2019 09:14:26 UTC