Currently working with a plugin called MixItUp and animating/filtering some elements according to their category. The problem I've got at the moment is that the vertical scrollbar seems to be causing some issues with the width of the page as the horizontal scrollbar appears after the elements have finished animating, but only for a split second.

I think it may have something to do with the vertical scrollbar adding a width which is pushing my elements to beyond the container, thus creating the horizontal scroll. However, though I'm aware Chrome doesn't calculate page widths the same as Firefox, IE etc, why are the calculations changing each time it animates? Also, this isn't just a problem in Chrome as it also affects Firefox.

I've looked into using a custom scrollbar so that I can control the width of it, which seems to work though I think implementing this fix would be very bad for usability.

I have a live demo on the following link - please could someone advise?

Okay, to give you guys a bit of a chance to see what is happening I have slowed down the animation on the live demo above. I think what may be happening is that the elements are going by the original total width before it starts animating (ie. with the scrollbar in place) but while the animation is playing through the scrollbar is still there, causing an extra 20px to be added to the calculation, creating the horizontal scrollbar.

However, once the animation is finished a re-calculation is made and because the vertical scrollbar is no longer needed, this 20px or so is taken away and the elements can be contained, hence the "snap-back" once the animation finishes. Any ideas on the solution?

I've taken a quick screen-grab to help demonstrate the above. Note that this was taken during the animation so the location of each element hasn't settled, hence the gaps in between the elements.

Cheers,

Shoxt3r

Shoxt3r
—
2013-10-19T11:30:01Z —
#3

I seem to have fixed that issue by adding a margin to the section which is the container to the grid and adding a float left. My problem now is that if I have less than 4 rows of elements the styling goes completely haywire and the elements squash down into a small space. I have no idea what is causing this as all of the styling at the moment is universal so each of the categories' boxes are all the same width etc.

To test please click on the "web" filter and you'll see what I mean. Any thoughts?

Fantastic! Thanks Francky! The problem I have now is that some elements seem to have a mind of their own, almost like they don't have styling applied to them until the last minute when they snap back into place? I've deliberately slowed down the animation so you can see it more distinctly.

Curiously it will only happen when you go from "All" to one of the others, never between each category. I assume because when they are mixed it has to do a lot more calculating. Is it the number of elements the browser has to handle?? :S Totally confused!

...snapping ... I assume because when they are mixed it has to do a lot more calculating. Is it the number of elements the browser has to handle??

No, I don't think so. Otherwise the backwards operation from a certain item to All (which has the same amount of elements) should have the same jumping problems.Confirmed: if I shrink the number of elements from 30 to 4, the problem is still there if I go from All to Photo:0.test-snapping-0.htmIn some way or another, it must be caused by the script (like a rounding of a % in the wrong way). For me the script is to complicated to get a finger on it. :rolleyes:But I got 'em in some experiments!

1.test-snapping-1.htmFirst I gave all elements an opacity of .6, except one. Now you can see better what happens: in this case when you go from All to Photo.The green Photo element is staying at his (her?) position until the last moment. It looks somehow like there is not enough place available to move earlier.

2.test-snapping-2.htmIn a Wild West Try I gave the items a margin-left of 1px, so there is more space between. That helped! The green Photo element is moving from the beginning (again from All to Photo).But now the items show a gap, and they consume to much width to fit horizontally: result a dropdown after 3 elements. Hopefully when that is restored, the moving will stay o.k. ...I tried adding a margin-right of -1px for compensation, and dropped a firm wish and flowers in the Old Wishing Well.

3.test-snapping-3.htmEcho! :lol:The smooth moving stays upright.Now only there is a horizontal scrollbar. due to the 1px shift of the total.

But what was happening in the dark caverns of the javascript, I don't know.

Tested in Firefox 23, not yet in other browsers.

PaulOB
—
2013-10-27T11:53:45Z —
#7

Good work Francky

Looking at the documentation the author states not to use floats but inline-block instead which may have solved some issue from the start ( but possibly have introduced others where no gap between images was required - although there are fixes for that).

Francky
—
2013-10-28T01:16:37Z —
#8

Good work Francky

Thanks, I should use the Old Wishing Well a lot more to solve problems! But I didn't read the documentation thoroughly... In the meantime I did some more tests.

General

When I tested on my wide screen laptop, it appears the snapping problem is only present if the window size is smaller than the max-width of 1280px of the body!

It is hardly visible because of the used colors, but in test 4 and test 5 a 1px black "border-left" shows up.

I tried several things in css to get rid of it, but no success. Playing with the inline-block didn't help, not other things I tried. Then I went to javascript: fight evil with evil. I set a fake link on the option items (All / Graphics / Web / Photo), with an onclick function which gives the grid items a temporary margin-left of -1px and a small timeout to go back to the normal {margin-left:0}. And some small css changes.

Unfortunately, Chrome and Opera are showing the 1px black background line again, now on the right side; adding a {margin-right: .05px;} for compensation doesn't work.

So I think the javascript solution is better. Unless somebody can provide an other css solution, of course.

BTW: Is something planned for the accessibility for visitors with disabled javascript, visitors with IE8, and for SEO? For them the MixitUp script is more MixitDown: nothing to see ... :rolleyes:

Shoxt3r
—
2013-10-29T13:32:07Z —
#9

Wow! Thank you so much Francky! Apologies for not being "responsive" ( ), I've been away for a long weekend so haven't had chance to catch up with my emails/forum posts. So after just having a quick skim-through of the posts and tests you've done (which I really, really appreciate you taking the time to do!) it would seem that it was down to the Javascript fighting against the CSS a little? Or would you say it was a problem with my HTML structure? Would appreciate some further feedback just so I know in myself if I could improve for later

Thanks once again and apologies for not getting back to this sooner!

EDIT: Regarding accessibility and SEO, this is something I'll be looking into next. It may just be a simple case of undoing the script so that it doesn't have a fade-in onload in which case it will just be static blocks. I'm not a great fan of the fade-in implemented by mixitup anyway