[css-view-transitions-2] How are invalid types validated?

[nt1m]

Apparently there are invalid types (see #9534):

type can accept any idents, except 'none' or '-ua-' prefixes

I would suggest throwing a TypeError or a SyntaxError when these are used in DOM APIs (notably the setters).

cc @noamr @khushalsagar @vmpstr @bokand

[nt1m]

cc @tuankiet65

[nt1m]

Aside from the DOM APIs, should the use of invalid names in the types descriptor of @view-transition make the declaration invalid?

(I personally think it should, for clarity)

[noamr]

See this resolution

We specifically allowed invalid types in the setlike setters, to be consistent with CustomStateSet where the set can include and reflect invalid values, but they're not selectable in JS.

I think this validation should be in @view-transition { types } and in :active-view-transition-type(), not sure it needs to be in CSSOM.

I think it's important that it would make the whole at rule invalid, otherwise an at rule with invalid types would trigger a transition as if it has no types.

[noamr]

I can't attend the APAC meeting, but proposing to leave the wording as is, as per previous resolution.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] How are invalid types validated?, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<TabAtkins> vmpstr: in VT we have a notion of "types" you can specify
<TabAtkins> vmpstr: there are some type names that are invalid, like "none" or anything with "-ua-*"
<TabAtkins> vmpstr: Tim asked how these are validated in the JS APi, and suggested throwing a syntax error
<TabAtkins> vmpstr: previously we resolved not to do validation in the script api
<TabAtkins> vmpstr: we just use what the author specified, but ignore the invalid bits
<TabAtkins> vmpstr: a silent filtering
<TabAtkins> vmpstr: we'd like to maintain that
<TabAtkins> vmpstr: also, the @view-transition supports types, and Noam's comment is that if there are invalid types, the pref is for the whole block to be invalid, otherwise it can cause unexpected transitions to happen
<fantasai> sounds reasonable to me
<TabAtkins> vmpstr: So I think we'd like close-no-change, tho it's not entirely clear to me that @view-transition reflects fully what I said above. But the script API side, at least, reflects what I said
<TabAtkins> astearns: In my reading of Tim's post, it sounds like he's fine as long as it's defined.
<TabAtkins> vmpstr: I have the same reading
<TabAtkins> fantasai: I checked with Tim and he's ok with resolving
<TabAtkins> astearns: so proposed resolution is close no change, it's already handled
<TabAtkins> RESOLVED: close no change