I’ve just recently implemented Isotope into my site to allow filtering of some elements (I’ve used it before but not with Bootstrap 4).
I’m having some problems with the tab spacing when filtering.
On load the padding is correct but if you select any of the filters the padding changes due to the page scrollbar disappearing, and then padding is only re-calculated when you click the filter again.
Below I’ve put together a quick Codepen to demonstrate my problem:
Steps to reproduce:
On load, observe that all tabs are visible (blue, orange and yellow), and a vertical, page scrollbar is present - if not, please resize the window so that the preview area is small enough to show a scrollbar.
Click on a filter button (“Web”, “Graphics” or “Photo”)
Observe that the padding between the tabs is different than the on-load version
Click on the same filter button again (e.g. if you click on “Web” before, click it again).
Observe that the tabs shift and the original padding is applied.
Optional: click “All” and note that the padding is correct without any additional clicking being needed.
As I say I believe this is related to the scrollbar appearing/disappearing - is there any way around this?
Reproducible in all latest versions of Chrome, Firefox & Edge.
Thanks in advance and let me know if you need any further information!
If you delete the footer and remove the max-width from the “wide-container” via the console, then switch between the Powertrains “All” and “FWD” you get the same result. I would say therefore it’s something to do with no max-width being set on my version.
Assigning 100.5vh to the body is another way of assuring that the vertical scrollbar is always visible. html{overflow-y:scroll} is better.
In what way is it a UX issue?
From my experience here, people complain about jumpy text as the page width adapts to the viewport width if the page height shifts between less-than viewport height and greater-than viewport height frequently.
With overflow:scroll the scroll bar will be grayed out until needed so there is no danger of a user scrolling.
I’m on a mobile at the moment so can’t look at the other issue you mentioned but I’m guessing you are just talking about the content re-centering when the width of the viewport changes due to the scroll bar appearing.
Thanks both - I’ve just tested the overflow-y CSS out and it works perfectly for my purposes - a shame I potentially have to have the scrollbar (see my “fix” below) but needs must I guess!
Regarding the issue I was pointing out on the Kia website, it’s actually the same issue I was having with my Isotope implementation. However, as the developers for Kia’s website have set the max-width of the container to a set value, they’ve negated the issue I was having - possibly as a by-product or maybe it was intentional to fix the problem?
For example, I’ve created a forked Codepen of my original example, but this time set a max-width on the tab container. This for some reason means that even with the scrollbar not being present, the calculations are completed correctly on the first filter click.
In other words, with a max-width set on the container, when a filter is clicked (and as the tabs animate into their final place) the margin between each tab is taken into consideration and there is no further recalculation needed to compensate for the scrollbar - thus on a secondary click of the same filter, no shifting of the tabs to compensate occurs.
I’m still a bit puzzled why the tab spacing needs to be recalculated when the container is set to full-width for it to appear correctly, but maybe I’ll raise this via their GitHub page and ask why.
Thanks again for your help - I now have 2 options, either set a max-width on the tab container or go down the route of having a scrollbar at all times if I still want the container to take up the full-width.
It sounds as though the available width of the viewport is being used to work out the padding required but when the number of elements are changed then a scrollbar appears/disappears and the width that was used at the start would be wrong. Clicking on the same tab a second time means that the correct width is used and therefore the padding is corrected. It looks as though the script should force a resize once its laid out the elements so that the routine can be called again.
If you use a max-width then nothing changes when a scrollbar appears or re-appears assuming the viewport is wider than the max-width.
Using html {overflow-y:scroll}, the scrollbar will be visible, but it will not show a “thumb” when the content is less than the height of the viewport; therefore, the user is not prompted to scroll (cannot scroll) up or down.
So it sounds like the available width should be checked when the number of elements change, just to make sure that it takes into account the scrollbar appearing/disappearing? Either way I think I’ll raise an issue to highlight it again as it’s been a long-standing problem like the looks of that link. Thanks for your help!
Good point - it looks like this is the “fix” that’s been referenced on the link Paul provided as well. Now to decide whether to restrict the width via max-width, just use a permanent scrollbar…hmm…
Yes but only after they have been laid out because it won’t be known if a scroll bar appears until the elements are drawn. Basically do it once then do it again.
Ok thanks for clearing that up!
I’ll raise that with them via the GitHub page then as it seems a major flaw. For now, I’ve implemented the scrollbar fix. Restricting via max-width seemed to work to some extent until you resized the window (could simulate if a user were to change the orientation of a tablet/phone) so the scrollbar fix seemed to be the most robust “solution”.
