[css-typed-om]: There's no nice way to represent CSSUnparsedValue as a "list-plus" style object.

[annevk]

Single-type iterables are reserved to certain legacy APIs with an indexed getter. I don't think we want that here.

@bzbarsky

[tabatkins]

WebIDL doesn't say it's restricted to legacy APIs? It does indeed say that you need an indexed getter and a .length property, tho - we can fix that.

[annevk]

Indexed getters are legacy for all intents and purposes. As they require a proxy to implement and are therefore not really natural.

[annevk]

(There's a open issue against IDL to get them renamed.)

[bzbarsky]

Yeah, I think we do want the indexed getter. People keep talking about it as if it were legacy, but we still have no decent solution for a lot of use cases.

That said, in this case we could perhaps use an Array-valued property. At least as long as it does not need to be live in any way. If liveness of some sort is needed, then we're back to indexed getters.

[tabatkins]

Nothing is live in the Typed OM. This is a serialization (in object form), and to change anything you have to explicitly set it again.

[annevk]

Yeah, I raised an issue earlier about this maybe just being an Array, but that got closed...

@bzbarsky what use cases though? We don't really want new live lists. And if you really need it, just have a method.

[bzbarsky]

Nothing is live in the Typed OM.

OK. Looks like you can't modify a CSSTokenStreamValue, so you could make it a frozen array, but...

@bzbarsky what use cases though?

Consider the case here, where you want to represent "iterable stream of tokens" in a thing that you could pass to StylePropertyMap.set. If you just make it an Array, you now have to make StylePropertyMap more complicated.

[shans]

I reopened #221 - it really shouldn't have been closed.

I'm OK with an Array, any objections? This definitely should not be live, and a simple representation is best.

Does the Array need to be frozen?

[annevk]

I think people decided they wanted to return frozen arrays where possible. I'm still not entirely convinced it adds value, but it seems to be the pattern we're using for now...

@bzbarsky because StylePropertyMap would have to accept an iterable and return an array rather than set/get of an object? Somewhat convincing, though I think the benefits of using a standard data structure outweigh that. (Ideally we'd have immutable standard data structures of course...)

[bzbarsky]

@bzbarsky because StylePropertyMap would have to accept an iterable

That depends. Is the idea to accept the new thing by reference or by value? Right now it accepts and stores it by reference, yes?

[shans]

The main issue is that CSSTokenStreamValue needs to be a subclass of CSSValue.

Making it an iterable and adding the indexed getters/setters seems like the best solution?