[css-view-transitions-2] Data type for types in script APIs

[khushalsagar]

@emilio brought up that because we want types to be readonly on the CSSViewTransitionRule, it shouldn't be a DOMTokenList. Filing this issue to clarify the data type across all script APIs.

• startViewTransition has a types param which is currently sequence.
• CSSViewTransitionRule has a types param which is currently DOMTokenList.
• ViewTransition has a types param which is DOMTokenList.

The ViewTransition is the only one that needs to me mutable. @noamr

[noamr]

@emilio brought up that because we want types to be readonly on the CSSViewTransitionRule, it shouldn't be a DOMTokenList. Filing this issue to clarify the data type across all script APIs.

• startViewTransition has a types param which is currently sequence.
• CSSViewTransitionRule has a types param which is currently DOMTokenList.
• ViewTransition has a types param which is DOMTokenList.

The ViewTransition is the only one that needs to me mutable. @noamr

We can't use DOMTokenList because it's tied to an element+attribute.
For ViewTransition.types, he closest equivalent would be a CustomStateSet. Proposing to have a ViewTransitionStateSet that's setlike (almost identical to CustomStateSet).
We should decide if this set can hold and reflect invalid values (non-idents, none, -ua-*). Proposing that it's more useful if it can't reflect invalid values.

For CSSViewTransitionRule.types, I think we should have a readonly setlike, like GPUSupportedFeatures.

[khushalsagar]

We should decide if this set can hold and reflect invalid values (non-idents, none, -ua-*). Proposing that it's more useful if it can't reflect invalid values.

+1 to the set not holding invalid values. We can drop those as a part of the setter algorithm.

For CSSViewTransitionRule.types, I think we should have a readonly setlike, like GPUSupportedFeatures.

SGTM

Any suggestion for this: "startViewTransition has a types param which is currently sequence"? There was also a question about potentially dropping this altogether now that mutable types is a trivial way to do the same thing.

[noamr]

We should decide if this set can hold and reflect invalid values (non-idents, none, -ua-*). Proposing that it's more useful if it can't reflect invalid values.

+1 to the set not holding invalid values. We can drop those as a part of the setter algorithm.

For CSSViewTransitionRule.types, I think we should have a readonly setlike, like GPUSupportedFeatures.

SGTM

Any suggestion for this: "startViewTransition has a types param which is currently sequence"? There was also a question about potentially dropping this altogether now that mutable types is a trivial way to do the same thing.

I'd say either dropping it or keeping it as a sequence is fine.

To clarify, what I propose as a resolution:

• use ViewTransitionTypeSet for ViewTransition.types (a setlike interface). This throws a type error when trying to add none, something that begins with -ua-, or anything that's not a valid custom-ident
• use CSSViewTransitionTypeSet for CSSViewTransitionRule.types (a readonly setlike interface)
• Optionally, remove the startViewTransition(callbackOptions) variant.

[nt1m]

Should we create a base type that is shared with CustomStateSet?

[noamr]

Should we create a base type that is shared with CustomStateSet?

The setlike mixin should be the right way to go about it IMO, there are lots of them around (e.g. FontFaceSet and [Highlight](https://drafts.csswg.org/css-highlight-api/#highlight. Each of those has different semantics for adding items, they don't really share functionality apart from the setlike interface.

[noamr]

Reciting @emilio's comment, perhaps it would be simpler/more consistent for the CSSOM version to have FrozenArray<CSSOMString> rather than a readonly setlike, (and allow duplicates there?)

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Data type for types in script APIs, and agreed to the following:

• RESOLVED: Use FrozenArray for CSS OM. VT typeset which is setlike for types attribute. Keep sequence of strings for svt as is.
• RESOLVED: dont deduplicate values in reflections
• RESOLVED: dont drop invalid values in reflections

The full IRC log of that discussion

<keithamus> astearns: first data type in script APIs for typed.
<keithamus> noamr: we reflect types we discussed in JS. We want to finish up exactly which data types we expose.
<keithamus> noamr: there are 3 of those.
<keithamus> noamr: 1. One that goes in the view transition object, VT types. Exposed as SetLike - viewtransitionstateset.
<keithamus> noamr: Basically exactly like CustomStateSet, a set of strings. It has side effect of changes types of VT.
<keithamus> noamr: Decide on reflecting only valid events, removes none etc. Or reflects everything like a set of strings
<keithamus> noamr: 2. CSS OM - readonlysetlike or frozenarray.
<keithamus> noamr: No strong preference. Precedence for readonlysetlike like gpu capabilities, which is readonlysetlike<string>
<keithamus> noamr: maybe css om can be simpler like a frozenarray
<keithamus> noamr: 3. What we pass to start view transition, its a sequence. We maybe don't need at all?
<emilio> q+
<astearns> ack emilio
<keithamus> emilio: when you specify duplicate names into cssrule theres deduplication? We don't generally do that. If at parse time I dont care if array or set. If we dont do parse time deduplication - I don't think we do - I think there was precedent but we undid it? If none then we should go with frozenarray. It's also simpler.
<keithamus> emilio: the rest sounds fine
<keithamus> noamr: we can decide if theres duplication or not
<khush> q+
<keithamus> noamr: deduplication is most convenient and performant to do first thing but its not... we can make a judgement call on frozenarray and do dedupe during VT rather than css parse
<keithamus> emilio: that sounds maybe more consistent, like color-scheme, but no strong opinion. If people are fine... classname is the same it doesn't get deduped during parse time
<keithamus> noamr: they're deduped in classList right?
<keithamus> emilio: only if you mutate, not the attribute value
<keithamus> emilio: either way is fine though, no objections
<astearns> ack khush
<keithamus> khush: invalid values? No question there that invalid items in the list are dropped at parse time?
<keithamus> noamr: right. The question is should we remove invalid values added with JS to the set? Should we throw? or discard? Or add to set but never match?
<keithamus> noamr: initial impl is a copy of customstateset, its a set of strings. Invalid strings wouldn't match because they don't get into css
<vmpstr> q+
<keithamus> noamr: last thing is - do we need types parameter in startviewtransition, or regular and mutate later?
<keithamus> fantasai: conceptually when you set up transition you set up types. Mutate later while running seems weird
<keithamus> noamr: call viewtransition then settypes? Some convenience inside start.
<astearns> ack vmpstr
<keithamus> vladhanter: Mild preference for keeping param in startviewtransition
<keithamus> khush: can be a sequence of strings
<keithamus> noamr: yep
<vmpstr> s/vladhanter/vmptr/
<keithamus> emilio: seems fine
<vmpstr> s/vladhanter/vmpstr/
<keithamus> noamr: frozenarray if duplicated would reflect back as string value, look like what you put in there.
<keithamus> khush: CSS OM is readonly right? Cant mutate?
<keithamus> noamr: right but would it dedupe? `foo foo`. One or both?
<keithamus> khush: if in css? Are both going to show up or single value.
<keithamus> noamr: yes. Also array style like includes or setstyle like has?
<keithamus> khush: ...
<keithamus> emilio: no you get both as string
<keithamus> emilio: we could also go for string. How font-face descriptors work if you specify lists.
<keithamus> noamr: also selectors are strings.
<keithamus> emilio: exposing new interface for that attribute might be overkill, you need for setlike. FrozenArray and strings, I don't care either way too much
<keithamus> noamr: string would be most CSSOM like.
<keithamus> noamr: a bit less useful
<keithamus> emilio: in practice you can split
<keithamus> astearns: if precedent for frozenarray, with better dev ergonomics, happy go with that. We dont need to follow string precedent
<keithamus> noamr: preference for frozenarray from this discussion
<keithamus> emilio: not sure if it has precedence in CSS OM but selectors nowadays would not be plain string, same for other apis
<keithamus> astearns: specify frozenarray, from impl experience if that is entirely new thing for cssom. Or push back to string if not.
<keithamus> emilio: even if completely new I think it's fine
<keithamus> noamr: in chromium not a problem
<keithamus> emilio: css om has observable arrays for mutable stuff so for ro frozen makes sense
<keithamus> astearns: resolution then?
<keithamus> PROPOSED RESOLUTION: Use FrozenArray for CSS OM. VT typeset which is setlike for types attribute. Keep sequence of strings for svt as is.
<keithamus> khush: one more thing is we dont dedupe
<keithamus> noamr: also dont check for invalid
<keithamus> RESOLVED: Use FrozenArray for CSS OM. VT typeset which is setlike for types attribute. Keep sequence of strings for svt as is.
<keithamus> PROPOSED RESOLUTION: dont deduplicate values in reflections
<keithamus> RESOLVED: dont deduplicate values in reflections
<keithamus> PROPOSED RESOLUTION: dont drop invalid values in reflections
<keithamus> RESOLVED: dont drop invalid values in reflections
<keithamus> emilio: just that we're not consistent with customstateset but...