[css-view-transitions] 'type' argument that takes an array of types is very weird naming

[fantasai]

See https://www.w3.org/2024/03/13-css-minutes.html#x269

It's very weird to have a singular noun representing an array of such nouns.

[vmpstr]

FWIW this comes from d6c50e9 I can't quite find the exact spot where we discussed this. The origin of a singular word here is that in CSS a list of idents is typically singular because of syntax (e.g. the only thing I can think of right now is animation-name), so we just matched javascript to that CSS name.

Should we have CSS type: <custom-ident>+ and JS sequence<DOMString>? types? to be consistent with each domain

[noamr]

The discussion about this was in TPAC 2023.
One solution to this is to not have a special startViewTransition signature at all, and instead:

const vt = document.startViewTransition(updateCallback);
vt.typeList.add(...theTypesIWantedToAdd);

[bramus]

(e.g. the only thing I can think of right now is animation-name)

A counterexample is font-family which you set to a list of font names. The property could as well be named font-name but instead it use the family suffix.

Rewinding a little bit back, I raised this concern because there were a bunch of different names for it, which seems a bit weird: types, type, and typeList (the types one turning out to be a typo in the spec).

I could see Noam’s suggestion above work, but then that would not solve the descriptor in the @view-transition rule, which still is type (at this moment).

Moving forward, I think the most consistent way to talk about this would be to use the term “Type List” across the board. In CSS that would become type-list (in the @view-transition rule) and in JS typeList (when passing it into startViewTransition(), when reading it from a ViewTransition object, and when reading it from CSSViewTransitionRule).

So, proposal: Use the term “Type List” across the board. That is, type-list in a CSS context and typeList in a JS context.

[noamr]

(e.g. the only thing I can think of right now is animation-name)

A counterexample is font-family which you set to a list of font names. The property could as well be named font-name but instead it use the family suffix.

Rewinding a little bit back, I raised this concern because there were a bunch of different names for it, which seems a bit weird: types, type, and typeList (the types one turning out to be a typo in the spec).

I could see Noam’s suggestion above work, but then that would not solve the descriptor in the @view-transition rule, which still is type (at this moment).

That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor.

Moving forward, I think the most consistent way to talk about this would be to use the term “Type List” across the board. In CSS that would become type-list (in the @view-transition rule) and in JS typeList (when passing it into startViewTransition(), when reading it from a ViewTransition object, and when reading it from CSSViewTransitionRule).

Is this consistent with anything existing in CSS atm? I was using the *List suffix only for a DOMTokenList which is consistent with classList.

[noamr]

@bramus also the new view-transition-class takes a list of idents and doesn't use the word "list".

[khushalsagar]

That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor.

The class vs classList is a good counter for why type in CSS is reasonable. But it feels like authors will have an easier time if its the same name everywhere:

1. at-rule
2. CSSViewTransitionRule
3. startViewTransition
4. ViewTransition object

2 and 4 are already using typeList. So could startViewTransition and the at-rule use typeList as well. We have to do typeList for CSSViewTransitionRule because of #9905.

[noamr]

That one is a list of idents though. It's equivalent to class, it's not a JS array. So I think type is fine for the descriptor.

The class vs classList is a good counter for why type in CSS is reasonable. But it feels like authors will have an easier time if its the same name everywhere:

1. at-rule

2. CSSViewTransitionRule

3. startViewTransition

4. ViewTransition object

5. and 4) are already using typeList. So could startViewTransition and the at-rule use typeList as well. We have to do typeList for CSSViewTransitionRule because of [css-view-transitions-2] CSSViewTransitionRule.type overrides deprecated CSSRule.type #9905.

I think if we do away with (3) (#10070 (comment)), having it type where we can is equivalent with existing things (class, view-transition-class, font-family, part...). We use typeList only because the word type is overused and sometimes conflicting (e.g. in CSSViewTransitionRule).

So I think using type in CSS but typeList in JS when it's a DOMTokenList is consistent enough with current things. But I'm happy to resolve on whatever we reach consensus around.

[khushalsagar]

Thanks for clarifying Noam. So sounds like we at least have consensus on renaming the type param in startViewTransition to typeList for consistency across all javascript APIs. Let me Agenda+ for that.

I have a stronger preference for type-list for the at-rule than type for the same arguments that were made on #9972. Makes it more obvious that typeList on the ViewTransition object is initialized using the descriptor in the CSS at-rule.

@nt1m @fantasai what's your preference?

[nt1m]

I tend towards types, there is precedent for using plural in descriptors (e.g. @counter-style has a few)

[khushalsagar]

^ Is there a reason to favour types over type-list, even though the latter maps directly to the script references to types.

[bramus]

I tend towards types, there is precedent for using plural in descriptors (e.g. @counter-style has a few)

As this point I was gonna suggest types as well. It describes what you are defining (hinting at possibility to add more than one), it’s vague enough to be correct in both CSS and JS land, and it makes it easy for the author to use: the thing is called types (independent of the context).

As you mention @counter-style has precedent for having a descriptor that is plural. Another one is @font-palette-values’s override-colors

[noamr]

I tend towards types, there is precedent for using plural in descriptors (e.g. @counter-style has a few)

As this point I was gonna suggest types as well. It describes what you are defining (hinting at possibility to add more than one), it’s vague enough to be correct in both CSS and JS land, and it makes it easy for the author to use: the thing is called types (independent of the context).

As you mention @counter-style has precedent for having a descriptor that is plural. Another one is @font-palette-values’s override-colors

I'm ok with this, we went with type because of a notion in the TPAC conversation that CSS doesn't use plurals. (I believe @tabatkins & @astearns raised this?)