- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Nov 2023 17:43:01 +0000
- To: public-css-archive@w3.org
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)`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> khush: Realted to a resolution we had a few weeks ago<br>
<TabAtkins> khush: to define the at-rule for authors to request a cross-document VT<br>
<TabAtkins> khush: What was left was naming<br>
<TabAtkins> khush: So this is to resolve on the naming<br>
<TabAtkins> khush: proposal is `@view-transition`<br>
<TabAtkins> khush: Two descriptors<br>
<TabAtkins> khush: First, 'navigation', defines what navigations this at-rule applies to<br>
<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.<br>
<TabAtkins> khush: But intention is "auto" means "all navigations that make sense".<br>
<khush> https://github.com/w3c/csswg-drafts/issues/8960<br>
<TabAtkins> khush: Other descriptor is 'type'. Related to a reoslution we had in #8960<br>
<TabAtkins> khush: Allowing multiple transitions happening in your doc, and you want to apply CSS depending on which is actually running.<br>
<TabAtkins> khush: We defined how that worked for JS-based VTs, so this is adding the same functionality to cross-document declarative ones.<br>
<TabAtkins> khush: Naming options are 'type-list', to be consistent with classList<br>
<TabAtkins> khush: Other is 'type' or 'types'. CSS doesn't seem to pluralize words, so 'type' is our proposal<br>
<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<br>
<TabAtkins> khush: Last question for input<br>
<TabAtkins> khush: There's a future extension to allow adding UA-defined keywords into this list<br>
<TabAtkins> khush: Like if we allow using this for declarative same-document transitions, there will be a keyword to opt into that.<br>
<TabAtkins> khush: So we want to make sure we can add UA-specified things to this later.<br>
<TabAtkins> khush: A few approaches - 1) the author supplies dashed-ident, so UA-provided ones will be undashed<br>
<TabAtkins> khush: Another is we reserve a prefix for UAs and don't let authors use that<br>
<TabAtkins> khush: We used that for animations already<br>
<TabAtkins> khush: So our proposal is you can supply any custom ident, but it can't start with `-ua-`<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: I think overall this makes sense. Preference for -ua- over dashed idents<br>
<TabAtkins> fantasai: More consistent with classes to allow anything<br>
<khush> +1<br>
<TabAtkins> fantasai: Curious about the comment where the default value is the empty list and ther'es no none value<br>
<TabAtkins> fantasai: We don't have props that can take an empty value anywhere in CSS, besides custom props<br>
<TabAtkins> fantasai: So I wonder if 'none' is the reasonable thing<br>
<TabAtkins> fantasai: Not something you have to specify, just to ahve a consistent way to refer to the empty list<br>
<Rossen_> ack khush<br>
<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.<br>
<TabAtkins> fantasai: I agree it's the same, it's just not a patten we have, where you can't say the default value.<br>
<fantasai> TabAtkins: No strong thoughts, but a little odd to have an empty value, we don't do anywhere except custom props<br>
<fantasai> TabAtkins: Can just leave it out<br>
<fantasai> TabAtkins: but generally, I'm slightly against omission being impossible to express explicitly<br>
<fantasai> TabAtkins: makes some types of code writing awkward to write<br>
<fantasai> TabAtkins: can't pass value, have to pass out-of-band value<br>
<fantasai> TabAtkins: so slightly for doing 'none' and making it a disallowed name<br>
<fantasai> TabAtkins: wouldn't block on it though<br>
<TabAtkins> khush: I'm okay with that. We'd disallow "none" in the JS API too to be consistent<br>
<TabAtkins> vmpstr: I think that's fine. We'd need to resolve that "none" is not a valid JS type<br>
<TabAtkins> khush: So reserved keywords would be "none" and the -ua- prefixes<br>
<TabAtkins> Rossen_: Can we resolve on that?<br>
<fantasai> PROPOSED: type can accept any idents, except 'none' and '-ua-*'<br>
<TabAtkins> (Note that for the JS API you ahve to rule out all ASCII-casing variations.)<br>
<fantasai> PROPOSED: type can accept any idents, except 'none' and '-ua-*' ; 'none' represents no idents (empty list)<br>
<TabAtkins> emilio: Do we need `-ua-`? We have `ua-` on font families<br>
<fantasai> do we? I thought we had system-<br>
<khush> +1 to Vlad<br>
<TabAtkins> vmpstr: We use `-ua-` for the keyframes right now, so I'd prefer being consistent<br>
<TabAtkins> (I think -ua- is correct; these aren't well-specified by the group.)<br>
<TabAtkins> RESOLVED: type can accept any idents, except 'none' or '-ua-' prefixes<br>
<fantasai> There aren't any font families starting with ua-. We have system-ui, etc.<br>
<khush> https://github.com/w3c/csswg-drafts/issues/9534#issue-1966514190<br>
<TabAtkins> khush: This issue has names for a few other descriptors as well on the first comment<br>
<TabAtkins> khush: So the at-rule name and the descriptor names.<br>
<TabAtkins> khush: Can we resolve on these?<br>
<TabAtkins> TabAtkins: Sure.<br>
<TabAtkins> fantasai: I'm fine in general. Slightly uneasy about "auto" because it's vague.<br>
<TabAtkins> fantasai: You're defaulting to same-origin, right? Previous we discussed using 'same-origin' as the keyword, do we want to do that?<br>
<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.<br>
<TabAtkins> khush: So it's kinda complex, seems appropriate for 'auto'<br>
<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<br>
<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.<br>
<TabAtkins> fantasai: k<br>
<fantasai> PROPOSED: at-rule is named @view-transition<br>
<khush> @view-transition, navigation: auto | none, type<br>
<fantasai> PROPOSED: @view-transition includes a 'navigation: auto | none' descriptor<br>
<TabAtkins> RESOLVED: at-rule is @view-transition, descriptors are 'navigation' and 'type', 'navigation' grammar is "auto | none" ('type' grammar already resolved)<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9534#issuecomment-1802364085 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 November 2023 17:43:03 UTC