- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 17:26:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] :active-view-transition-type() and reserved keywords interaction is not defined`, and agreed to the following:
* `RESOLVED: ban ua-* and none at parse time as types, in :active-v-t-type() and @view-transition types descriptor`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> emilio: this one was weird<br>
<TabAtkins> emilio: whether ua-prefixed stuff is allowed in the types list wasn't particularly defined<br>
<TabAtkins> emilio: same with :active-view-transition<br>
<TabAtkins> emilio: I matched Chrome, I think it's reasoanble<br>
<TabAtkins> emilio: we may want to make :active-view-transition-type(none) invalid<br>
<TabAtkins> emilio: so we need to define exactly when the invalid UA thing is allowed<br>
<TabAtkins> emilio: so a while ago we reserved -ua- prefix for ua-dependent VTs<br>
<TabAtkins> emilio: when I went to implement I realized wk and blink implemented it weird<br>
<TabAtkins> emilio: the idents are valid in the Selectors, along with none<br>
<TabAtkins> emilio: and same in v-t type set, what you pass in startViewTraansition<br>
<TabAtkins> emilio: but they dont' actually match at "match time"<br>
<TabAtkins> emilio: I thought the idea is that CSS.supports("active-view-transition-type(-ua-...)") would return false<br>
<TabAtkins> emilio: spec is handwavey<br>
<TabAtkins> emilio: i'm fine with current behavior but it's a little silly<br>
<TabAtkins> emilio: think banning would be better, but it does raise questions about the js api<br>
<TabAtkins> emilio: no strong opinion but need to resolved<br>
<vmpstr> q+<br>
<TabAtkins> emilio: Noam commented that changing to reject -ua- and none in the selector sounded fine<br>
<TabAtkins> emilio: should probably do the same for @view-transition<br>
<TabAtkins> emilio: probably need extra checks in the VT type set<br>
<TabAtkins> emilio: so proposal is to make -ua-* and none invalid in :active-view-transition-type and in @view-transition's 'types' descriptor<br>
<astearns> ack vmpstr<br>
<TabAtkins> vmpstr: no problem with none<br>
<TabAtkins> vmpstr: and the rest<br>
<TabAtkins> vmpstr: q about ua-prefixed<br>
<TabAtkins> vmpstr: I thought the idea of those is that the UA adds some of these types<br>
<TabAtkins> vmpstr: for the author to be able to query, via :a-v-t-type()<br>
<TabAtkins> vmpstr: so resolving to not allow it would preclude that<br>
<TabAtkins> vmpstr: trying to remember what the ua-rpefixed types are for, then<br>
<TabAtkins> vmpstr: if the author can't style based on that<br>
<TabAtkins> emilio: I thought that, for VT names, we banned ua-* prefix so match-element can use it<br>
<TabAtkins> emilio: for type, I assume it was for consistency<br>
<TabAtkins> vmpstr: I agree with banning ua-* names for the reason you said. just can't think of a reason to ban it for types<br>
<TabAtkins> vmpstr: I don't think the spec mandates any ua-* types right now, Chrome doesn't add any<br>
<TabAtkins> emilio: either they're banned or not, they're just in a weird state rn where they're disallowed from matching<br>
<TabAtkins> vmpstr: ah if they're banned from matching we can ban them outright.<br>
<emilio> https://github.com/web-platform-tests/wpt/blob/0f8fc11dda/css/css-view-transitions/view-transition-types-reserved.html<br>
<TabAtkins> vmpstr: just don't remember why we have the match ban in the first place<br>
<TabAtkins> astearns: is the ban for matching types just accidental, because we banned matching names?<br>
<TabAtkins> emilio: it's very intentionally tested, it was apparently authored by Vlad<br>
<vmpstr> 2 years ago!<br>
<TabAtkins> emilio: I do think banning them makes sense<br>
<TabAtkins> emilio: they're just weird state right now<br>
<TabAtkins> vmpstr: might as well ban them. we can revisit if there's a use-case<br>
<TabAtkins> astearns: so proposed is that we ban ua-* and none at parse time as types, in :active-v-t-type() and @view-transition types descriptor<br>
<TabAtkins> RESOLVED: ban ua-* and none at parse time as types, in :active-v-t-type() and @view-transition types descriptor<br>
<TabAtkins> astearns: anything in the JS API that needs to error?<br>
<TabAtkins> emilio: in the API you can specify an arbitrary list of idents<br>
<TabAtkins> emilio: pretty useless if you cna't specify. we could remove them.... it interacts a bit weirdly with setlike, guess we'd need to throw in some places<br>
<TabAtkins> emilio: to me, if you can't match them it's okay to just leave them there<br>
<TabAtkins> vmpstr: I think we resolved to add :active-view-transition-type(*) at a prev meeting<br>
<TabAtkins> vmpstr: so there is a q if you just specified the disallowed types, does * match?<br>
<TabAtkins> vmpstr: presumably you want to treat the * as if you'd already filtered to exclude the banned types<br>
<TabAtkins> vmpstr: actually unsure anyone's implemented * yet<br>
<TabAtkins> emilio: guess it's okay to filter from the API. should we just throw when you specify those?<br>
<TabAtkins> vmpstr: mildly prefer to filter the list silently<br>
<TabAtkins> emilio: that's fine<br>
<vmpstr> +1<br>
<TabAtkins> astearns: maybe leave the JS alone for now?<br>
<TabAtkins> emilio: yeah that's basically just leaving it unfiltered until matching<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13141#issuecomment-4179337871 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 17:26:35 UTC