- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2019 09:14:25 +0000
- To: public-houdini-archive@w3.org
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