- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Dec 2022 18:00:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-transitions-2] Start transitions on discrete animation types`, and agreed to the following: * `RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition` <details><summary>The full IRC log of that discussion</summary> <bramus> astearns: thanks oriol<br> <bramus> flackr: in current spec we explicitly dont transition discrete aniamtions types. we skip<br> <bramus> flackr: with resoltuion to animate display it would be useful for devs to transition discrete properties<br> <bramus> flackr: example in linked issue<br> <bramus> flackr: proposal is that we allow transitioniong discrete props but to preserve compat the all keyword would only match animatable types<br> <smfr> q+<br> <bramus> flackr: only if dev lists explicitly lists a discrete property it would transition<br> <astearns> ack smfr<br> <bramus> smfr: … timing function? steps timing to contorl when the value flips?<br> <bramus> flackr: sure you can<br> <bramus> flackr: step and step-start<br> <bramus> smfr: is there [missed] … the animation? wondering if timing function> .5 that is where discrete things flip<br> <bramus> flackr: my proposal is not to do something special here<br> <bramus> flackr: means that you can use any fn that crosses .5 treshold<br> <dbaron> You can also use a different transition-delay for the discrete property if you want to.<br> <bramus> smfr: trying to underrstand implications<br> <bramus> flackr: all would only include animatable props<br> <bramus> smfr: mech for keyframes?<br> <bramus> flackr: already the case. not building any new anim behavior here<br> <bramus> smfr: havent quite got in my head yet. is there a dif between props that animate discretely and those not at all?<br> <bramus> flackr: yes. you cant animate aninaton-name for example<br> <bramus> smfr: what about display?<br> <fantasai> well, we resolved to draft such a proposal into the css-display-4 draft<br> <bramus> flackr: we resolved on display last week<br> <bramus> smfr: doesnt this already work by virtue of .5 behavior?<br> <bramus> flackr: there is line in spec that limits to only animatable and not discrete<br> <bramus> tabatkins: you can animate a discrete prop but not transition one<br> <bramus> flackr: with waapi, devs can listen to transitionstart<br> <bramus> flackr: they could use this to enable transitions we do not support yet<br> <bramus> astearns: easier acces<br> <bramus> flackr: possible to acces. before no transitionstart ( = custonization point)<br> <masonf> q?<br> <bramus> plinss: some props are discrete because they are difficult to animate<br> <bramus> plinss: if an engine figures out how to make a discrete prop animate: is that allowed and would it then be treated as normal animated property?<br> <bramus> flackr: yes and yes<br> <fantasai> plinss++<br> <bramus> flackr: and would then be picked by up by `transition: all`<br> <bramus> plinss: can we detect this?<br> <astearns> ack fantasai<br> <bramus> fantasai: example: animate between 2 background imgs.<br> <bramus> fantasai: tarnsitionable with easing curbe<br> <bramus> fantasai: what would happen if it became animatable? compat problems? might be fine<br> <bramus> flackr: cases for waapi and css anims. they dont have a mechanism to know when the become animatable<br> <bramus> flackr: you could use this to feature detect if property is discrete or not<br> <fantasai> s/tarnsitionable with easing curbe/if author transitions with a particular easing curve assuming discrete/<br> <bramus> plinss: we may want to consider an `@supports` for this<br> <bramus> astearns: yes<br> <masonf> q?<br> <bramus> astearns: do we add ability to tell sth is discrete or animatable?<br> <masonf> q+<br> <astearns> ack masonf<br> <bramus> masonf: point out that there is an optional part 2 to add a new keyword<br> <bramus> astearns: lets discuss after<br> <astearns> ack fantasai<br> <bramus> fantasai: proposal is that you explicitly list a property that is discrete it will transition. whe you provide an easing curve it will flip at 50%?<br> <bramus> flackr: yes. latter part already implied by how animations work<br> <bramus> fantasai: seems reasonable<br> <bramus> astearns: proposed resolution: if a discretely animateable property is listed in a trantion it will. by default the all keyword will not transition<br> <bramus> flackr: anders said it better there, but effect is the same<br> <bramus> RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition<br> <bramus> astearns: 2nd part: can we have all opt in to this behavior?<br> <bramus> flackr: 2 options: other type of all keyword that is actually all, or a keyword to target discrete<br> <astearns> ack fantasai<br> <masonf> q+<br> <bramus> fantasai: i think if there is no demand we should not add it. idea to add discrete makes more sense.<br> <bramus> fantasai: you can then use it to apply a certain curve to only the discrete ones<br> <flackr> E.g. transition: all 1s ease, discrete step-end 1s;<br> <astearns> ack masonf<br> <bramus> flackr: example in irc is sth devs might do<br> <dholbert> q+<br> <bramus> masonf: +1 on discrete keyword<br> <bramus> astearns: i can see value in this<br> <astearns> ack dholbert<br> <bramus> astearns: but I might want to see actual real tarnsitions with particular groups of discrete props taht would be solved by this keyword before we resolve to add it<br> <astearns> s/see value/see theoretical value/<br> <bramus> dholbert: concern where prop changes from discrete to not discrete<br> <bramus> dholbert: could be problem for minor content<br> <bramus> dholbert: also curious for use cases<br> <bramus> flackr: first part already problem bc all matches [missed]<br> <bramus> flackr: second part less defined right now<br> <bramus> astearns: you can do custiomzation now by having discrete property explicitly listed, separetely from all<br> <bramus> flackr: yes<br> <bramus> flackr: do see value in discrete keyword<br> <bramus> flackr: but also fine with exploring use cases first<br> <bramus> astearns: what about a note in the spec that we consider this keyword and ask authors for use cases (or if we come up with some)?<br> <masonf> +1<br> <bramus> flackr: sure<br> <bramus> astearns: thats it we are at time<br> <argyle> 👋🏻<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4441#issuecomment-1351867996 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 December 2022 18:00:57 UTC