[css-view-transitions-2] resolve on descriptor/parameter names

[noamr]

The current editor's draft defines a few new names.
We should resolve whether they're the right names or should be changed.

Current spec:

/* css */
@view-transition {
  navigation: auto | none;
  type: foo bar;  
}

:root:active-view-transition(foo) {
  img.hero {
    view-transition-name: hero;
  }
}

/* js */
document.startViewTransition({
  update: () => { ... },
  type: ["foo", "bar"]
});

viewTransitionRule.type // DOMTokenList

Proposed Resolution

• The navigation-type descriptor is navigation, and its current possible values are auto and none.
• The type descriptor is type. Its default value is an empty list. There is no none value or so.
• The JS parameter for startViewTransition as well as the property name in the CSSOM rule can be typeList, to be consistent with classList, as it receives some sort of iterable. Alternatively we can keep it as type or use types.
• Bonus: decide whether the types can be regular idents vs. using dashed-idents for future compatibility with keywords.

[khushalsagar]

One question which can use the group's input, should we require dashed idents for type? That helps in making sure we can add UA defined keywords later. But we don't have any such requirement for other VT properties with keywords like view-transition-name.

[vmpstr]

One of the resolutions #7560 (comment) says that we should use -ua- prefix for the keyframes, and presumably use this pattern elsewhere as needed. Is this one of the cases where this pattern qualifies? That is, allow custom-idents except ones with a -ua- prefix that are then reserved?

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] resolve on descriptor/parameter names, and agreed to the following:

• RESOLVED: type can accept any idents, except 'none' or '-ua-' prefixes
• RESOLVED: at-rule is @view-transition, descriptors are 'navigation' and 'type', 'navigation' grammar is "auto | none" ('type' grammar already resolved)

The full IRC log of that discussion

<TabAtkins> khush: Realted to a resolution we had a few weeks ago
<TabAtkins> khush: to define the at-rule for authors to request a cross-document VT
<TabAtkins> khush: What was left was naming
<TabAtkins> khush: So this is to resolve on the naming
<TabAtkins> khush: proposal is `@view-transition`
<TabAtkins> khush: Two descriptors
<TabAtkins> khush: First, 'navigation', defines what navigations this at-rule applies to
<TabAtkins> khush: Currently just "auto" and "none". "none" means don't do it at all. "auto" loosely means "do it for all navs except reloads". We have an issue for improving the precision.
<TabAtkins> khush: But intention is "auto" means "all navigations that make sense".
<khush> https://github.com//issues/8960
<TabAtkins> khush: Other descriptor is 'type'. Related to a reoslution we had in #8960
<TabAtkins> khush: Allowing multiple transitions happening in your doc, and you want to apply CSS depending on which is actually running.
<TabAtkins> khush: We defined how that worked for JS-based VTs, so this is adding the same functionality to cross-document declarative ones.
<TabAtkins> khush: Naming options are 'type-list', to be consistent with classList
<TabAtkins> khush: Other is 'type' or 'types'. CSS doesn't seem to pluralize words, so 'type' is our proposal
<TabAtkins> khush: And to make it obvious it's the same capability in the JS api, whatever we pick here will be the same as we use in the JS API
<TabAtkins> khush: Last question for input
<TabAtkins> khush: There's a future extension to allow adding UA-defined keywords into this list
<TabAtkins> khush: Like if we allow using this for declarative same-document transitions, there will be a keyword to opt into that.
<TabAtkins> khush: So we want to make sure we can add UA-specified things to this later.
<TabAtkins> khush: A few approaches - 1) the author supplies dashed-ident, so UA-provided ones will be undashed
<TabAtkins> khush: Another is we reserve a prefix for UAs and don't let authors use that
<TabAtkins> khush: We used that for animations already
<TabAtkins> khush: So our proposal is you can supply any custom ident, but it can't start with `-ua-`
<Rossen_> ack fantasai
<TabAtkins> fantasai: I think overall this makes sense. Preference for -ua- over dashed idents
<TabAtkins> fantasai: More consistent with classes to allow anything
<khush> +1
<TabAtkins> fantasai: Curious about the comment where the default value is the empty list and ther'es no none value
<TabAtkins> fantasai: We don't have props that can take an empty value anywhere in CSS, besides custom props
<TabAtkins> fantasai: So I wonder if 'none' is the reasonable thing
<TabAtkins> fantasai: Not something you have to specify, just to ahve a consistent way to refer to the empty list
<Rossen_> ack khush
<TabAtkins> vmpstr: My understanding is because the blocks aren't cascading, it's either set or not set, having an explicit default value isn't necessary.
<TabAtkins> fantasai: I agree it's the same, it's just not a patten we have, where you can't say the default value.
<fantasai> TabAtkins: No strong thoughts, but a little odd to have an empty value, we don't do anywhere except custom props
<fantasai> TabAtkins: Can just leave it out
<fantasai> TabAtkins: but generally, I'm slightly against omission being impossible to express explicitly
<fantasai> TabAtkins: makes some types of code writing awkward to write
<fantasai> TabAtkins: can't pass value, have to pass out-of-band value
<fantasai> TabAtkins: so slightly for doing 'none' and making it a disallowed name
<fantasai> TabAtkins: wouldn't block on it though
<TabAtkins> khush: I'm okay with that. We'd disallow "none" in the JS API too to be consistent
<TabAtkins> vmpstr: I think that's fine. We'd need to resolve that "none" is not a valid JS type
<TabAtkins> khush: So reserved keywords would be "none" and the -ua- prefixes
<TabAtkins> Rossen_: Can we resolve on that?
<fantasai> PROPOSED: type can accept any idents, except 'none' and '-ua-*'
<TabAtkins> (Note that for the JS API you ahve to rule out all ASCII-casing variations.)
<fantasai> PROPOSED: type can accept any idents, except 'none' and '-ua-*' ; 'none' represents no idents (empty list)
<TabAtkins> emilio: Do we need `-ua-`? We have `ua-` on font families
<fantasai> do we? I thought we had system-
<khush> +1 to Vlad
<TabAtkins> vmpstr: We use `-ua-` for the keyframes right now, so I'd prefer being consistent
<TabAtkins> (I think -ua- is correct; these aren't well-specified by the group.)
<TabAtkins> RESOLVED: type can accept any idents, except 'none' or '-ua-' prefixes
<fantasai> There aren't any font families starting with ua-. We have system-ui, etc.
<khush> https://github.com//issues/9534#issue-1966514190
<TabAtkins> khush: This issue has names for a few other descriptors as well on the first comment
<TabAtkins> khush: So the at-rule name and the descriptor names.
<TabAtkins> khush: Can we resolve on these?
<TabAtkins> TabAtkins: Sure.
<TabAtkins> fantasai: I'm fine in general. Slightly uneasy about "auto" because it's vague.
<TabAtkins> fantasai: You're defaulting to same-origin, right? Previous we discussed using 'same-origin' as the keyword, do we want to do that?
<TabAtkins> khush: Right now we're same-origin but exlcude reloads, and have an issue to discuss whether typing a same-origin URL into the nav counts too.
<TabAtkins> khush: So it's kinda complex, seems appropriate for 'auto'
<TabAtkins> fantasai: Ok, I don't have a better idea right now. Feel like it could benefit from more explicit, but dn't have a suggestions
<TabAtkins> khush: So I suggest we resolve on "auto" now. We have an issue for strictly defining "auto", we can talk about a more specific name at that point.
<TabAtkins> fantasai: k
<fantasai> PROPOSED: at-rule is named @view-transition
<khush> @view-transition, navigation: auto | none, type
<fantasai> PROPOSED: @view-transition includes a 'navigation: auto | none' descriptor
<TabAtkins> RESOLVED: at-rule is @view-transition, descriptors are 'navigation' and 'type', 'navigation' grammar is "auto | none" ('type' grammar already resolved)