This is working for me in Firefox so if you use a different browser can you just run a quick check? Hidden Responsive Stack To Centered Button Bar Menu
If that passes I'll write up the step by step tutorial, like the off canvas menus (below).

So what is supposed to happen is it's a centered expanded button row in medium and above then when you go to mobile it transitions a fixed icon that scrolls with the page and that opens a hidden responsive stack, but this one shouldn't disappear.

I noticed the RSD navigation component (Navigation - Glass with drop) diaspears when it diminished and resized in Firefox so I thought I'd have a go fixing it with foundation 6.3.1
Not a fan of the foundation buttons so I'll do the next one with a nested UL drop menu but anyway this one I also may make it so it opens the stack on mobile in a fixed top position too.

Seems to behave the same as Firefox, with Chrome v58 and IE v11.

Regards,
Gordon

In FX the menu appears stacked briefly at the point that it switches to mobile version.

Thanks Gordon now I know I have a fix for the built in component. I'll write this up, maybe if coffeecup wants to they can use it to repair theirs in the future?

Thanks Eric, when you diminish the desktop across to check the mobile you will get a FOUC (flash of unstyled content) from a phone that wouldn't happen since it goes to the mobile orientation and stays in it to landscape with the hidden stack.

What I'm seeing is the old build with the grinder grid it was back loading around 15KB js with the shiv, picturefill and respond and around 140KB for the CSS grid & your main CSS which you could pare down using proper style stacks... The html then the jQuery library from a CDN if you included it so loads from the footer. So that was a nice efficient load.
This foundation build is fairly heavy on the backend in comparison. It front loads more js to process, the foundation.min, jQuery.min and a couple of other small ones, so a little over 200KB of js. Then it loads the foundation.min CSS 200KB before it starts to load in your main CSS and html. So you may have noticed the difference especially if you have a smaller bandwidth. Newer PC's can process faster though now too though. Still you'll get the FOUC more with this build in my humble opinion.

What Eric reports is also true in Waterfox (the 64-bit edtition of Firefox). The flash occurs as one reduces the screen width from 640 to 639 pixels, but it does not appear at either a screen width of 639px or a screen width of 640px.

I have no real idea as to what may be causing this, but have wondered whether it may be connected with a matter to which I've already drawn the attention of the CoffeeCup team. Borders may be set allegedly in pixels in the Design panel, but that is not truly what happens: looking at the CSS section of the Inspector panel reveals that they're actually set in rems, and this can have a significant effect in some browsers*. The main.css of the site in the first post of this thread reveals that such conversion has occurred there.

Frank

*It did not happen with the Coffeegrinder framework, but has caused me a lot of work in trying to convert some items to the Foundation framework.

PS. Alter Eagle's far more technical explanation appeared while I was typing this. FC

Did you check on orientation change?

My previous wondering (about rems and pixels) proves to be not relevant, but I think I may have identified what is relevant.

Removal of lines 93-106 of the main.css file cures the problem. Presumably all that is necessary is to achieve in some other way what those lines were meant to do.

Frank

Eric, if you mean on mobile? I did, it works on the iPhone.

Frank, those are the flex codes to convert it to vertical for mobile. So really it's dragging the desktop smaller you get the FOUC where the processor looks for and implements the style change from the classes. If you were on mobile it would load that in. At least that's my guess... it's been quite a few years since I looked into how the DOM works but I believe when you use a class it processes all the classes, where an ID is faster and is looked for first. I don't think that would make a difference in this case but just more pontificating than anything. I think that's where the heavy back end on these libraries come into play since they have to be written generic, but it sure is easier than working out these grids by hand.

Hi Alter Eagle.

Indeed so. The flex is being used to render the buttons vertically, but I doubt that flex is the only way of doing that. Without the aforementioned lines in the main.css file the flash doesn't occur.

I guess therefore that there is a work-around, but I personally doubt that it is worthwhile, as few, if any, people would see the flash, or take any notice of it even if they saw it.

Frank