bob2517
commented
1 year ago Changing back to original plan: 1) cancel-pause: all;
At some point this will command work with labelled pauses, but for now, for my work thing, I just need all the pauses in any animation events going on to be cancelled when the page switches, which this will do in one command. A delayed single action like "after 1s" isn't exactly the same as a pause, technically, and I now feel in hindsight that it could be a mistake to mix these two together. This move also keeps things backward compatible and just feels like a better solution.
I have a work project, purely written in ACSS, fully SPA, massive website, where the front page has a series of staggered animations in the hero section of the page.
This is currently achieved using triggered events with labelled timers. When the page changes to a "new page", ie. the screen updates via ajax, the animation is cancelled via its timers. I've got other page transition animations going on in addition to this front-page, so I can't use cancel-timer-all, otherwise it would cancel the page transition animations too. So I have to cancel each front-page animation timer individually.
The code is a bit messy as a result of all these triggered animations happening at different times. It's hard to see what is going on with those animations. It would be a lot worse if done in native JS, so it is still better than it would have been if done natively.
To solve this extraneous mark-up issue, it would be better to utilise the pause command to simplify the chained animations. I could reduce the number of chained animations to three events, which would simplify things a lot. Currently there are around a dozen+ events.
The problem is that you can't currently cancel the pause command. It will only run to the next command if the element is on the page, but the problem is that the animation will continue if the page is gone out of and then immediate gone back into again. It will just think that the page hasn't changed. So I had to use triggered events with labelled delays. By using pause instead, I could have done a workaround, monitoring the state of the page and barfing out of the next command if the page had just been drawn, but again, that's even more mark-up and we end up with the same issue of code waste.
A simple solution would be the ability to 1) cancel all pauses currently in progress. That would handle the situation in one command. I don't use pauses for the page transition animations at all, so all the pauses could be cancelled without affecting the general running of the site navigation. Or 2) Cancel individual pauses with labels. This would be a similar solution, but each event would need cancelling, which is a little bit more code and complexity than we need compared to 1). With 1) we get a re-factoring on the command syntax level.
I don't need number 2 yet, but this would be a full solution for the future.
So in summary for this issue:
1) Write a cancel-all-pauses command (or a command named like that); 2) Integrate pauses to work with labels and the existing cancel-timer functionality.
This will probably be the only important thing left to implement before work commences on version 3 and the developer extension. Enough production projects have been done now to know what works and what needs refinement, and I think this is the last major thing that could be improved, excluding any outstanding bugs if they get spotted meanwhile.