-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Remove css props rather than setting transition to none #9284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Remove css props rather than setting transition to none #9284
Conversation
✅ Deploy Preview for tiddlywiki-previews ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Confirmed: CrossEye has already signed the Contributor License Agreement (see contributing.md) |
📊 Build Size Comparison:
|
Branch | Size |
---|---|
Base (master) | 2537.6 KB |
PR | 2538.7 KB |
Diff: ⬆️ Increase: +1.1 KB
There seem to be some problems with the pop and zoomin storyview
Tested with FF on ubuntu 24.04 |
I've addressed the comments made so far, removing I think I have |
Works now for me on FF and Edge - Windows 11 |
Removing the "WIP:" prefix. This is ready to commit, if the team is interested. But I do think we should investigate this more widely. The more we use CSS animations, the less we want hard-coded element style properties staying around when the element is at rest. I think we might want to look at where else we might use such techniques. |
See the Talk discussion on Prerelease animation for more background.
This replaces a number of post-animations blocks that set an element's CSS
transition
property tonone
with ones that remove that style property altogether. If fixes an issue in which, after an element has been animated into the story river,:hover
transitions stop working.Although @saqimtiaz suggested looking also at
/core/modules/utils/dom/modal.js
and atcore/modules/utils/fakedom.js
, I didn't see any necessary changes there. I did find two others,slide.js
andcecily.js
.Testing
Do we have any automated testing feature that would help demonstrate the fix? I don't know that I've ever seen a programmatic way to assert that a CSS animation runs on precipitating event. Has anyone else?
One simple question
Should we add a function so that these lines would be replaced with
$tw.utils.removeStyle(targetElement, "transition")
(or possiblyremoveStyles
using an array of names)?A harder question
Should we take this time to review all such JS animation resets and replace all the
$tw.util.setStyle
calls with a property removal instead? There is a good argument to be make for doing so, but it is a substantial amount of work. And it seems as if testing would be quite difficult. Even recognizing when we're resetting to defaults rather than to arbitrary values might be difficult.