- From: vrugtehagel via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Apr 2021 06:53:50 +0000
- To: public-css-archive@w3.org
I indeed agree with option 3 there. We can already leave out the start and end of a keyframe animation; the specs clearly state > If a 0% or from keyframe is not specified, then the user agent constructs a 0% keyframe using the computed values of the properties being animated. If a 100% or to keyframe is not specified, then the user agent constructs a 100% keyframe using the computed values of the properties being animated.` I would not like to change this; `via` should not be able to "replace" `from` and `to`. Writing a keyframe animation like so: ```css @keyframes hop { via { transform: translateY(-10px); } } ``` would mean it resolves to 50%, while, as the specs currently specify, 0% and 100% will be constructed using the computed values. I think the biggest ambiguity we have is what happens when, for example, someone writes ``` @keyframes fadeOutIn { 0%, 90% { opacity: 1; } via { opacity: 0; } 50% { opacity: 0.5; } } ``` Even without the `via` keyword, this is hard to read, but I admit the `via` keyword adds some complexity as I now have to think about what it represents. Note that, while writing this is possible, it should be encouraged that authors write their keyframe selectors in order when using `via` to increase readability. Either way, the above would logically be equivalent to ``` @keyframes fadeOutIn { 0% { opacity: 1; } 50% { opacity: 0.5; } 70% { opacity: 0; } 90% { opacity: 1; } } ``` That is, even when using keyframe selector lists (such as `0%, 90%`) the order will be relevant to how `via` will behave (should it follow, be included in, or precede such list). -- GitHub Notification of comment by vrugtehagel Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6151#issuecomment-812357136 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 2 April 2021 06:53:52 UTC