Animations issues
Closed this issue · 10 comments
I started a quick project and decided to use Fluidbox for image gallery. I use Fluidbox 1.4.3 and jQuery 1.11.1. The website is http://lunabynw.com/ (https://github.com/smutnyleszek/lunabynw-com) and I have some visual issues with animations:
On latest Chrome and Safari the "loading square" is completely static and the image opening animation is not working after the first time. On latest Firefox the "loading square" works, but the opening and closing animation is not working at all. There is also a z-index problem with closing animation - the image being closed is behind all the previous ones.
The same opening and closing animation problems I'm experiencing on your demo page.
I'm running Fluidbox with default configuration:
$('a[rel="lightbox"]').fluidbox();
I have forgotten to add that the loading animations are powered by CSS3 animations, so you might want to include vendor prefixes manually in the CSS file, or use prefixfree.js to add appropriate vendor prefixes without any modifications to the CSS file.
I am unable to replicate your issue with the latest version of Chrome, v41. In Safari it is not working due to the requirement for the -webkit- prefixes for both CSS transform and animation.
Will include that missing information in the readme.
Update: Further testing reveals that the failure to position (by means of CSS translation) the loader properly is a bug within Safari itself, as I am unable to replicate the issue with Firefox and Chrome. Strangely enough switching between tabs will force Safari to render the positioning correctly.
I can reproduce this issue running Chrome 40 on Win7 64 and Chrome 40 on Android 5.0.2. The Fluidbox works correctly when one clicks on the image for the first time. Afterwards clicking on it results in the issue above.
Update: Reproduceable with the provided demo page and the browsers above.
yea sadly I have that problem with the opening animation too…
really bugs me, cuz its ruins the elegance of the plugin.
as far as the loader goes, I have a comment:
it seems the loader/spinner is constantly animated.
I would say that is not a good idea, depending on how many instances there are
this can have a bad impact on the sites performance.
I have noticed performance problems with animations, particularly with rotation…
regardless of that I would say a spinner should only spin when its indicating a loading process,
that can be done via a css rule, once loading is happening and a class is toggled.
But personally I would wanna remove the loading spinner all together…
There is a yet-to-be-fixed issue with the loading, but if you toggle the immediateOpen option to true, that should solve the issue (as far as I know).
The loading animation is done with the CSS rule (.fluidbox-loading) via a pseudo-element. You can comment it out and/or override is as of when you see fit.
yea I already did removed it from the css.
my critique is that animation is currently spinning constantly.
so anyone whos not removing the element is having animated elements that are being constantly calculated. (my asssumption atleast)
I can't seem to produce your issue of two concurrent spinning loaders. There is no constantly spinning element (unless you have an image that takes an extended amount of time to load) because the spinning animation is only enabled when the .fluidbox-loading class is assigned. The class is being toggled in between states, and are not present when (1) fluidbox is closed and (2) fluidbox is fully open.
mhm ok so i have images wrapped in anchors, href and img src are identical.
once they are visible in the layout there is no additional loading required for the fluidbox
but in the dom i do see the fluidbox-loader …
the fluidbox-loader has the pseudo element which is animated constantly.
the fluidbox-loading just sets opacity of fluidbox-loader to 1 and transitiondelay to 0 on the pseudo element.
hope I am being clear enough this time
the animation should be in this selector. (currently is not)
.fluidbox-loading .fluidbox-loader::before {
opacity: 1;
transition-delay: 0s;
-webkit-animation: fluidboxLoading 1s infinite;
animation: fluidboxLoading 1s infinite;
}
"animation-fill-mode: forwards"
should be used aswell in that case, I believe.
Hey guys,
I apologize for the late reply—real life got a bit too busy lately.
Anyway, I released a pre-release (the oxymorous of that name!) for v1.4.4. I think I might have fixed the zooming transition issue afterall—can't seem to be able to replicate it on my end on Firefox, Safari, and Chrome. If all fails, I suggest using immediateOpen: true for all. I am considering to remove this feature if this issue does not get resolved in a reasonable fashion, because it has been causing end users a lot of unnecessary frustration, which I am sorry about.
@derGraph, the animation fill mode has been modified, it should look better now. Thank you!
The latest release: 5c8a089. The demo page has been brought in sync with the latest commit, do check it out.