- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Aug 2022 16:58:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Make aniamtion shorthand syntax future-proof`, and agreed to the following: * `RESOLVED: All animation longhands not defined in Animations 1 are defined as reset-only sub-properties, while we work on how to make them specifiable without ambiguity.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Make aniamtion shorthand syntax future-proof<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6946<br> <TabAtkins> seb: We have an issue with new animation-* properties, that animation-name makes problems in the shorthand<br> <TabAtkins> seb: You can't distinguish animation names from the keywords from the other properties<br> <TabAtkins> seb: So how do we make it so that new properties, like animation-composition, can make it into the shorthand?<br> <TabAtkins> seb: One way would be to create a new optional syntax that separates the name from the rest with a slash, or something<br> <flackr> q+<br> <TabAtkins> seb: This would be optional, we couldn't enforce it on current property values<br> <TabAtkins> seb: This would hopefully be a gradual replacement, like with the color function syntaxes.<br> <TabAtkins> q+<br> <astearns> ack flackr<br> <TabAtkins> flackr: I think another possibility is that, for new properties, they will only be used if they are unambiguously not the animation name (youv'e specified another property before them)<br> <TabAtkins> seb: So making the order more fixed?<br> <TabAtkins> flackr: Until an animatino-name is specified, assume that all keywords are from the current set, not the new set<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: So we take the current set of keywords allowed in animation shorthand right now<br> <fantasai> TabAtkins: and until you see any keyword other than those, we only parse those as keywords<br> <fantasai> TabAtkins: anything else, including keywords from additional properties, assumed to be an animation name<br> <fantasai> TabAtkins: and as soon as we see an animation name, we start parsing the rest as other properties<br> <fantasai> TabAtkins: [gives example]<br> <fantasai> flackr: Correct<br> <TabAtkins> seb: Dunno if websites are already using animation names with the current keywords<br> <fantasai> Sebo: If authors are using these keywords now what happens?<br> <fantasai> TabAtkins: [missed]<br> <TabAtkins> flackr: ONe complication - with animation-timeline we've added another arbitrary name to the shorthand, potentially<br> <TabAtkins> flackr: So we might want a way to future-proof these other properties with arbitrary names<br> <fantasai> TabAtkins: for future arbitrary-name ones, we might need to add them with a prefix like "phase"<br> <fantasai> TabAtkins: but still have to handle animation-name today<br> <fantasai> TabAtkins: My suggestion was that I do actually like the slash syntax, assuming address future things in a specific ways<br> <fantasai> TabAtkins: I like animation-name being able to specify with a slash so unambiguous where it is<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: Stricter alternative of what flackr suggested<br> <TabAtkins> dbaron: Maybe easier to explain<br> <TabAtkins> dbaron: We only extend the shorthand if animation-name is first<br> <TabAtkins> dbaron: So rather than having "these have to be after the name, these dont'"<br> <TabAtkins> dbaron: Maybe the stricter rule of animation-name is first, and then you can use the new stuff<br> <flackr> +1 sgtm<br> <TabAtkins> astearns: Does the current shorthand have position restrictions?<br> <TabAtkins> TabAtkins: No<br> <TabAtkins> dbaron: I think Tab's explanation isn't quite what it is, but my memory is pretty old now<br> <TabAtkins> astearns: So if someone today is using a composition shorthand as the animation name, and it's put last, would this change make that declaration invalid?<br> <Sebo> Just for reference, here's the syntax: https://drafts.csswg.org/css-animations/#typedef-single-animation<br> <TabAtkins> fantasai: The canonical order puts the name last, so there's probably author sheets doing that today, and also script-generated values<br> <TabAtkins> fantasai: I think we'll have to fork the syntax in some way<br> <TabAtkins> fantasai: Need more brainstorming<br> <astearns> s/using a composition shorthand/using animation-composition/<br> <TabAtkins> fantasai: And we'll need to accommodate more custom idents too, as flackr mentioned<br> <astearns> ack fantasai<br> <dbaron> Just one example of how things work today: `animation: ease-in ease-out` is an animation where ease-in is the timing function and ease-out is the animation-name.<br> <TabAtkins> fantasai: For now, we can treat animatino-composition as a reset-only property, so it's reset by the 'animation' but can't be set in there<br> <TabAtkins> fantasai: That'll work to unblock while we solve the issue.<br> <TabAtkins> +1<br> <TabAtkins> Right, the non-name proeprties get first dibs on keywords, and animation-name takes the first unclaimed one<br> <TabAtkins> seb: So I heard two suggestions - a slash, or putting the name first and other keywords afterward<br> <TabAtkins> astearns: Possibly `name foo` instead of slash too<br> <TabAtkins> fantasai: I think we need to explore the syntax space, but not on the call<br> <TabAtkins> fantasai: We haven't yet used these kind of keyword indicators in property syntax, only in functions, so this'll be a first time.<br> <TabAtkins> I'm currently future-proofing a toggle proeprty by doing a keyword prefix, actually<br> <TabAtkins> astearns: So suggestion is we mark animation-composition as a reset-only sub-property for now, and work on a syntax allowing it to be set<br> <TabAtkins> fantasai: All longhands not in Animations 1 treated as reset-only for now<br> <Sebo> +1<br> <TabAtkins> RESOLVED: All animation longhands not defined in Animations 1 are defined as reset-only sub-properties, while we work on how to make them specifiable without ambiguity.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6946#issuecomment-1233190360 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:58:25 UTC