- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Aug 2022 16:29:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Scoping keyframe names in UA stylesheet`, and agreed to the following:
* `RESOLVED: Name UA-defined @keyframes rules with a -ua- prefix (and presumably use this pattern elsewhere as needed)`
* `RESOLVED: The -ua- names *are* usable in author/user stylesheets.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: Scoping keyframe names in UA stylesheet<br>
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7560<br>
<TabAtkins> khush: Came up in impl for Shared Element Transitions, where the browser is making keyframes and using in the UA stylesheet<br>
<TabAtkins> khush: Per spec right now, those @keyframes names can collide with author keyframes<br>
<TabAtkins> khush: Issue has two proposals<br>
<TabAtkins> khush: First is implicitly carrying source information around, so a UA 'animation-name' rule will look in the UA sheet first for keyframes<br>
<TabAtkins> khush: Main issue with this is there's a bunch of script APIs which provide the keyframe name, and it becomes difficult for authors to tell which @keyframes is being referred to<br>
<TabAtkins> khush: Alternate is making a syntax for keyframes names that can only be used in the UA stylesheet<br>
<TabAtkins> khush: Tab's suggestion was `@keyframes ua(foo) {...}`<br>
<flackr> q+<br>
<TabAtkins> khush: Could be implicit or explicit, but would be `animation-name: ua(foo)`<br>
<emilio> q+<br>
<TabAtkins> khush: Also an issue if author stylesheets are allowed to explicitly use the value. Prefer not, it gives us more flexibility to change.<br>
<TabAtkins> khush: I suggest we take TAb's suggestion of a ua() function<br>
<Rossen_> q?<br>
<Rossen_> ack fantasai<br>
<fantasai> ua(name-of-animation)<br>
<fantasai> -name-of-animation<br>
<fantasai> -ua-name-of-animation<br>
<TabAtkins> fantasai: Tab has several proposals. One is a function, another is a single-dash prefix, which isn't generally used, or specifically a `-ua-` prefix.<br>
<TabAtkins> fantasai: Just wanted to point out several options.<br>
<fantasai> s/options/options in the issue/<br>
<TabAtkins> khush: I think single-dash can be used in an author stylesheet, so there's some compat risk.<br>
<TabAtkins> flackr: The author stylesheets might refer to these for SET, right?<br>
<fantasai> SET=Shared Element Transitions<br>
<TabAtkins> flackr: My issue with scoping to the stylesheet (not allowing usage in author stylesheets) is authors might want to specify overrides for the proeprties that still use SET animation names<br>
<Rossen_> ack flackr<br>
<TabAtkins> khush: This can be done without overriding animation-name, by setting the longhang properties specifically.<br>
<TabAtkins> khush: Just not a fan of allowing using it in a different context from where it's intended<br>
<TabAtkins> flackr: That does prevent author from using the shorthand, tho<br>
<TabAtkins> khush: yeah<br>
<TabAtkins> flackr: So I have a slight preference for just using a naming convention, not putting a usage restriction<br>
<Rossen_> ack emilio<br>
<TabAtkins> emilio: I don't know if SET - it seems we want to expose the animatino to authors in some way<br>
<TabAtkins> emilio: We have other at-rules in the UA sheet that we don't expose tho, like a @font-face<br>
<TabAtkins> emilio: We just don't expose that in scripting APIs<br>
<TabAtkins> emilio: Is that an option?<br>
<TabAtkins> emilio: Otherwise I tend to lean to just using a naming convention.<br>
<Rossen_> q?<br>
<TabAtkins> emilio: There are use-cases for overriding animation names in user stylesheets, for example<br>
<fantasai> TabAtkins: When you don't expose the name in scripting APIs, the name is still exposed in properties?<br>
<fantasai> TabAtkins: If the author defines something of the same name, it would take precedence, right?<br>
<fantasai> emilio: We chose -moz- prefixed things, since supposed to be internal implementation detail<br>
<fantasai> emilio: naming convention, especially if we use -ua-, would allow user to override internal if they wanted<br>
<fantasai> emilio: so that's what I meant, there may be a use case for users to adjust animations<br>
<TabAtkins> fantasai: I think a naming convention is nice. Can decide if we want it to expose to the author or not for tweaking, but it allows that possibility. Seems usable/used in other places where we've run into similar problems.<br>
<TabAtkins> khush: So is there a preference for one of the naming conventions?<br>
<TabAtkins> fantasai: If it's author-exposed, I think -ua-foo is clear and fits into the syntaxes we might use it pretty easily.<br>
<fantasai> s/easily/easily anywhere we need such a thing/<br>
<TabAtkins> emilio: Agreed. No new syntax and it's reusable for other features.<br>
<bradk> +1 for -ua- for reasons already mentioned<br>
<TabAtkins> Rossen_: So sounds like a -ua- prefix is getting the most likes<br>
<TabAtkins> Rossen_: Can we resolve?<br>
<TabAtkins> khush: So consensus on -ua- prefix for UA-defined keyframes rules.<br>
<TabAtkins> khush: And a second question about whether this can be used in author stylesheets or not, I'm not clear if there's objections on that yet.<br>
<TabAtkins> Rossen_: So let's take those separately.<br>
<TabAtkins> Rossen_: First, the prefix naming. Any objections to -ua- prefix?<br>
<TabAtkins> RESOLVED: Name UA-defined @keyframes rules with a -ua- prefix (and presumably use this pattern elsewhere as needed)<br>
<TabAtkins> Rossen_: Second, expose them to be usable in author stylesheets?<br>
<TabAtkins> No opinion here<br>
<TabAtkins> RESOLVED: The -ua- names *are* usable in author/user stylesheets.<br>
<bradk> Hopefully auto prefixers will not start adding-ua- to everything.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7560#issuecomment-1233161987 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 31 August 2022 16:29:02 UTC