Nodebb: Animation glitch for search

[RoiEXLab]

• NodeBB version: Latest version (could reproduce on community.nodebb.org)

There is this annoying glitch that occurs when opening the search bar, either on a screen that is too small (reproducable with 140% zoom on community.nodebb.org at 1920x1080) or with too many items for the screensize in the navbar.

It would be nice if this could get fixed.

[pitaj]

This belongs on the persona repo

[barisusakli]

$('#search-fields input').on('focus', function () {
   $('#main-nav').addClass('hidden');
}).on('blur', function () {
  setTimeout(function () {
    $('#main-nav').removeClass('hidden');
  }, 100);
});

Don't hate me.

[RoiEXLab]

@barisusakli I wanted to throw in some interesting observations:
The Problem seems to be related to the page scrolling control

If it's actually visible, the "glitch" makes actually far more sense. Also if I simply modify the HTML in the Inspector to display: none; for this bar when it should be invisible anyways, this "glitch" doesn't actually occur anymore in the first case.
So this issue only occurs because the "invisible" but present scroll control takes up space that forces the bar to wrap. Because the animation of the Search button disappearing and the search field appearing are not perfectly aligned, the space that is occupied first grows larger than actually and then shrinks slightly, causing the bar to wrap for the short amount of time taking up more space than needed.

Related, but slightly Off-Topic

Of course everything still looks weird when there's too much in the Title bar for the screen to handle, but this is a different issue:
I'd recommend using display: flex; For the title bar. Flex-boxes are a real pleasure to work with compared to weird logic using float: left|right etc. Also they'd allow the items to shrink a little bit to ensure everything stays in a single line which would make this issue redundant.
Also I believe the Title bar is going way too late into "mobile mode" i.e. when all the other content already looks mobile-friendly the title bar still has this broken 2-line look

[julianlam]

Re-designing the title bar to use flexbox is a good idea, something we can consider. I'll add some context to the navigator here, though -- the reason why it is opacity and not display is because we originally wanted to have it fade in and out when it is needed/not needed. Doing it in such a way so that it fades out and applies display: none; is hard with CSS transitions, though I am certain it is not _impossible_ :smile:

[RoiEXLab]

I don't really have issues with the Tilebar being non-flex, but from my personal experience it turns out that flexbox is so much easier to use without any css frameworks like bootstrap ^^

[julianlam]

Contrary to my (since-deleted) reply, this is actually harder to do than expected, if I wish to fulfill the existing behaviour, which is _fade-in when needed, fade-out when not_. Whatever I do to modify either display or width cause issues with the _fade-out_ portion of the animation.

I stepped back and thought more about the problem here, which is that the navigator takes up a discrete amount of space. Ideally, we'd like it to take up zero space when not visible, so that the header bar doesn't get shifted to two rows, but even if it were possible, you'd still run into issues where when the navigator is visible, you'd see it on two rows anyway, so you'd want to solve the underlying issue first.

That being said, the underlying issue is that excessive amoutns of header items (or a small browser window) cause issues with the header bar spilling onto two rows, so perhaps switching this to flexbox may mitigate the issue somewhat (though I don't exactly see how, since it's a matter of trying to shove too many things into too small a space)

[RoiEXLab]

@julianlam My experience with flexboxes is a very good one in that regard:
You can give the elements inside such a box weights i.e. assign them a priority for their width, so if screen runs out, the elements with the lowest priority shrink first.
Also you can specify a "no wrap" CSS property (I don't remeber what it's called), so that the content never wraps at all, just shrinks it (at some point it will of course get too small, but at least no wrap).
Of course this doesn't solve all problems on its own: The icons have a more or less fixed size, so that can't be changed a lot. Might be enough for my specific case, but probably not for all screensizes greater than mobile screens.

Here's my Idea on a possible solution to this problem with too little:
When searching for something, the navigation options are probably not really important, so hiding at least some of them to make space for the search bar might be an option worth trying.