At some point we've broken the animations that should appear when adding a new tag to a tiddler. See this old archived version for an example:
https://web.archive.org/web/20140706113703/http://tiddlywiki.com
The reason that the animation has been lost is because one of the containers of the newly added tag pill is being refreshed, losing the animation state. To fix it, we need to ensure that the change of adding the new tag doesn't cause any extraneous refreshes.
wow, I didn't know there was an animation :grin:
do you have an idea which one might be that naughty container?
I haven't dug into it yet, but I'd expect to be see the nodes in question flashing in dev tools as we add a new tag.
The animation subsystem is rather neglected and brittle, but quite powerful. We've also somehow lost the animations when entries are added and removed from the open tab.
We've also somehow lost the animations when entries are added and removed from the open tab.
yes I've noted that but I found it's too much... but I was wondering once when I changed something within the "Open" tab why there was that storyview="pop" attribute. now it's clear
I haven't dug into it yet, but I'd expect to be see the nodes in question flashing in dev tools as we add a new tag.
I'll also look at this when I have time
What's the advantage to have this animation? IMO animations should be there, if something unexpected happens. So the user can see, what's going on. .. This isn't the case for the tags input.
From my point of view, we should remove all the animation config stuff there to decrease UI code complexity.
@pmario - I share your opinion in this case
The rationale for animating adding/removing tags is pretty basic: the location in which the tag appears is not adjacent to the place where the user clicked/focused in order to add the tag. So we animate the tag to draw attention to the change.
@pmario , now I also share @Jermolene's opinion :rofl:
ok ... I always forget, that the tags are sorted.
seems that the animation broke between the last tiddlywiki version without editor toolbar and the one introducing it
I put some console.logs into storyviews/pop.js - seems that it doesn't even use its insert function ... the animation should be applied there, right?
I became a bit suspicious when I noticed that the tags don't show any signs of transform styles applied
This thing here kicks in:
// Abandon if the list entry isn't a DOM element (it might be a text node)
if(!(targetElement instanceof Element)) {
console.log("returning bc not instance of elem");
return;
}
the targetElement here is in fact a #text node and not the <span> of the tag
Ha! This is an easy fix, my tags are animating. What about yours? :grin:
I've added two PR's for the tags in the edittemplate and for the "Open" tab
I cannot figure out why the viewtemplate tags don't animate
The animation for Viewtemplate - tags seems to fail because the tag is added before the listwidget knows about it. the list widget then handles list changes and the index of the tag is already defined and therefor it doesn't go into insertListItem where the storyview-animation would be triggered
Thanks @BurningTreeC
Most helpful comment
What's the advantage to have this animation? IMO animations should be there, if something unexpected happens. So the user can see, what's going on. .. This isn't the case for the tags input.
From my point of view, we should remove all the animation config stuff there to decrease UI code complexity.