@mixin font-face($style-name, $file, $family-folder, $category:"") {
    $filepath: "/assets/fonts/" + $family-folder + "/" + $file;
    @font-face {
        font-family: "#{$style-name}";
        src: url($filepath + ".eot");
        src: url($filepath + ".eot?#iefix") format('embedded-opentype'), url($filepath + ".woff2") format('woff2'), url($filepath + ".woff") format('woff'),url($filepath + ".ttf")  format('truetype'), url($filepath + ".svg#" + $style-name + "") format('svg');
    }
    #{$style-name} {
        font: {
            @if $category != "" {
                family: unquote(#{$style-name}), unquote(#{$category});
            }
            @else {
                family: unquote(#{$style-name});
                weight: normal;
            }
        }
    }
}

Useage:

@include font-face('body-font', 'im_fell_dw_pica_pro_roman', 'im-fell', 'serif');

Still having the same issue on 5.2.1 Even the page at zurb: http://foundation.zurb.com/docs/components/orbit.html fails on Win7/IE9

Can you show this actually working with F5. Nothing I do seems to work with CSS3 columns.

Same here w/no errors. The slides all appear on top of each other and do not cycle.

If you're using SASS with sematic coding, setting this to false will eliminate the styles for unused components from compiling into your final css file, making it much smaller. Only the styles you use will be used.

Do you just want to hide the sidebar on the small size?

http://foundation.zurb.com/docs/components/visibility.html

Or do you want a menu of the sidebar that is hidden on the small size but appears when the hamburger icon is pressed?

http://foundation.zurb.com/docs/components/offcanvas.html

Have a look at this: http://www.thecssninja.com/javascript/pointer-events-60fps this may not be related to your issue, but it is a best practice none-the-less, espically for slower devices.

.push and .pull shift the column left or right in the grid. Say you had a left sidebar on the desktop screen size, on the mobile size you would not want it to appear above the main content. You could use push on the sidebar and pull on the main content to effectively make the sidebar occur below the content on the mobile size.

Another common use for this is to include the primary content higher in the html for seo, and then to use .push and .pull to alter how the content displays. This way you can have a sidebar on the left that is actually below the primary content in the markup.

This may help: http://webreflection.blogspot.com/2006/12/reset-element-css.html

IMO It's best to avoid Photoshop and work with live prototypes, especially if you're working on a responsive site. This is just my opinion, but there is a growing trend promulgated by several high-profile designers to avoid using Photoshop because of how it limits the creative process. Here are a few articles for you to consider:

http://37signals.com/svn/posts/1061-why-we-skip-photoshop

http://24ways.org/2009/make-your-mockup-in-markup/

http://bradfrostweb.com/blog/post/the-post-psd-era/

Of course there are those who will disagree with this concept.

Personally, I am using rapid prototypes instead of wireframes or static mockups. Once the client has signed off on the content structure and layout, we move on to the actual designs. I've found it much easier and a lot less work this way. It all depends on your workflow and personal preference, but I've found that if you get the client to sign off on a rapid prototype, this will minimize those endless rounds of design tweaks while they are really just making up their minds about layout.

If the client realizes that after the prototypes are approved, any design changes that would change the layout or content structure must be re-prototyped and will warrant change order fees, then they are much less likely to "fiddle" with the site.

Also, using a prototype functions much like using greeked text in an ad. If you allow the client to focus on the design first, then they will fixate on how things look and fail to consider how thing are actually going to work. They will inevitably skip over details that will cause impactful changes later. It is a lot less effort to change code in a prototype than it is to alter, re-slice a PSD, and update all of that CSS which just changed.