Schizophrenia!

I think my problem is linked to @media instructions and the associated real-time movement of my header elements as the viewport is widened or narrowed. These movements (eg when the nav menu changes from 3-bar to text) have never been particularly elegant on my site as the text menu seems to jump down over the slider briefly as it manoeuvres into position. But in the past, these movements were only apparent in real-time window expansion/contraction: if the window stopped re-sizing during an @media transition then the element would jump into its correct position. The problem now is that it sometimes doesn’t sort itself out and the temporarily displaced @media elements stay in their displaced positions if the window stops expanding/contracting close to an @media transition point.

Here’s another example of two windows open at the same time, close to the 3-bar menu transition point. In the top window, the nav menu has weirdly wrapped itself onto 4 lines and therefore hangs down over the slider. It remains there, even if I expand or contract the window, until I force the page to re-load. For some reason, the slider image is rendered a few mm higher as well, even though both windows are exactly the same size.

Having assumed that one of my @media CSS instructions was causing the problem, I tried removing those bits of code but this didn’t fix the problem.

Next I will look at the php and CSS code for my extra header widget which holds the Search tool. I’m wondering whether this container re-wraps as it moves across the window during re-sizing, thereby forcing my main nav menu container to re-wrap too. And yet, the Search bar hasn’t moved from its default position in my top image so how could its container be forcing my nav menu onto 4 lines? (Scratches head.)

In most real-world scenarios, this issue wouldn’t manifest itself because most visitors won’t play around with their window width. But I still need to figure it out.

??
I would like to see your site, but I know you can’t show me it atm.
So, wanna try a “drastic” solution (if it works)?

.tc-header [class*=span] {
-moz-transition: none;
-webkit-transition: none;
-o-transition: none;
transition: none;
}

No-one can see the future more clearly than a blind man.

d4z_c0nf, I don’t know what you did there but it fixed my problem!

You are a genius.

Thank you.

Please can you reverse-engineer your solution to explain why I was suffering from schizophrenia? (Probably I still am – but the symptoms have disappeared…). I deduce that you have replaced the gradual responsive header transitions with a clean/instant re-positioning, as I can no longer see my main nav menu flying across the screen to take up its new position; therefore the nav menu can no longer “freeze” in mid-transition…

PS. Is it possible to kill other progressive transitions too? Sometimes my slider image jumps up on a transition and can freeze in that position and I’m thinking the instant transition might fix that. Sidebars too?

PPS. I’m wondering if I could convert you into an iPhone app?

Heheh.
Yes I did what you have deducted. The weird thing is that “freeze”.. shouldn’t happen, don’t know if it’s a problem of your safari version or what else.
You can apply that rule to all spans just removing .tc-header, and if it doesn’t work everywhere, adding !important to those (to give to the rules higher weight).
About the slider.. don’t get.. when resizing?

@chappie, just picked up this link yesterday which is well worth a read to understand the more intricate CSS settings.

@rdellconsulting – thank you…that is a brilliant link that every newbie should read and learn.

Lots of stuff there for me to play with. I’ve only ever used a handful before.

OK – first the bad news…

My displaced/wrapped main nav menu is back.

Now the good news…I know what is causing it.

Now more bad news…I don’t know how to fix it.

And finally, some more good news…It probably doesn’t matter.

I can open my viewport wide and reduce it to the minimum width a thousand times and the problem doesn’t materialise. But if I click once on the 3-bar menu icon to display the drop-down menu and then open the window wide again, the main menu will freeze as illustrated in my screengrab.

The good thing about this is that the number of visitors having both the facility and the inclination to expand a 3-bar menu screen to the point where the full menu is displayed will surely be infinitesimal.

But the bad thing about it is that it will, nonetheless, keep me awake at night.

I knew I had a problem with my 3-bar menu because, for some time, I have been afflicted with a doppelg?nger drop-down menu which only appears, fleetingly, when I close that menu. I have tried, without success, to fix it. And I’m willing to bet that this coding error of mine is what is causing my main menu display corruption.

Since I can’t show you the problem in real time but if anyone can be bothered to take a look at my style sheet to see what I’ve doe wrong, it’s here.

Thank you.

I’ve given up on a few things like this because I’ve come to the conclusion that I’ve simply hit a browser bug.

I spent weeks trying to improve on the CSS for the round-div animations around the featured images (exploring techniques without overlay borders). I had the perfect code, but the browsers simply wouldn’t render it the way they should have done. Instead of a smooth transition, I got a messy jumping around.

And you only have to look at the way some small touch devices deal with the featured images to realise that some of this is still frontier stuff. (The featured images’ messy behaviour on these devices is not bad coding in Customizr; it’s bad rendering in the devices.)

Some of the transition effects are simply not what they should be. But most users will never drive their browsers to the point we do, as they aren’t constantly resizing their browser windows like we do. (And on may devices, you cannot resize at all.) So they will generally see the perfection you intended.

I know that this won’t stop you trying to fix it: it wouldn’t me, either ??

(BTW, your site is looking seriously ace-cool bananas.)

@electricfeet – you’re very kind: viewed dispassionately, my site has been created by @nikeo, @rdellconsulting, @acub, @d4z_c0nf, yourself and the other great architects who built this place. I’m just a kid with a box of Lego.

And yes, I will keep gnawing away at this one. If you have that gene (aka OCD), you can’t do anything else. I can’t write it off as a browser bug because I’m certain it’s my bug — and anyway, my frozen-displaced-menu? glitch and my doppelg?nger-recoiling-dropdown? glitch both appear in all the browsers I’ve looked at.

However, there may be a clue in the unique way that Firefox renders my 3-bar menu on mousedown: in that browser only, mousedown causes my 3-bar button to jump to the right although the dropdown menu renders in the same central position as the other browsers. But when I click on the menu button a second time to dismiss the dropdown, the button jumps back to the left (where it’s meant to be) and it takes the dropdown with it.

The difference with Firefox is that I can’t see two recoiling menus at the same time: dropdown happens centrally in all three browsers but in Safari and Chrome, menu recoil is rendered centrally as well as on the extreme left. Firefox’s menu recoil is in the wrong place (extreme left) but it only renders one recoiling menu.

Unfortunately, because the animation happens so quickly I can’t grab the recoiling menu with my cursor to inspect the element; but the answer must lie somewhere in my style sheet… and I will find it.

Well, I’ve found the offending code (and what I think is a bug). Deleting this CSS snippet fixed my frozen-displaced-menu? glitch – and also fixed (or masked) my doppelg?nger-recoiling-dropdown? glitch:

/* MOVE 3BAR MENU DROPDOWN TO ALIGN WITH SEARCH */
div.nav-collapse.tc-hover-menu-wrapper.in.collapse {
position:relative;left: 80px; top:0px;
width:190px;
}

I don’t have a clue why it caused havoc but it did. Trouble is, without it my 3bar dropdown menu is so narrow that the menu item text won’t fit on it – see this screengrab.

Why it is so narrow, I don’t know. It wasn’t always this way but I can’t find any other snippets in my CSS which modify the default. So, I’m now looking for a harmless bit of code which doubles the width of my 3bar dropdown menu – without causing havoc elsewhere. Any suggestions would be very welcome.

[The aforementiontioned “bug” is what is causing the top third of my slider image to disappear north, as illustrated in my screengrab – but I’ll start a new thread for it.]

Probably ’cause its parent (.navbar.resp .navbar-inner) is that narrow.
Using the rule below results in?

.navbar.resp .nav-collapse.collapse {
width: 190px; /* if it's enough for you, you can also play with media queries and/or use percentages like 150% (of its parent)*/
}

Thanks d4z – initially, your snippet widened the dropdown but half of it was invisible off screen to the left.

Adding position:relative;left: 50px; brought the whole menu into view – but has also caused the 3bar button to jump to the right as well (although it jumps back to the left on mousedown and then stays on the left unless I refresh the screen in which case it jumps to the right again until I click it.

Yeah but adding position:relative and left: something, you basically reproduce the initial issue..
So the thing is, why your dropdown responsive menu is placed off screen?

Yeah but adding position:relative and left: something, you basically reproduce the initial issue..

Not quite: I no longer see the original glitches. The only remaining issue is that the 3bar menu button jumps to the right when the page loads but reverts to the left once clicked.

So the thing is, why your dropdown responsive menu is placed off screen?

I’ve scoured my CSS for a clue but can’t find one.