Foundation has been a popular framework for people to build websites quickly and with ease. There are some fantastic advantages to Foundation – including an easy grid layout, and add on components like Top-bar, lightbox and mobile menu.
However, using a framework will always come with a few pitfalls that are easy to fall into, especially as a beginner using Foundation. In this article our junior web developer Claire, will go over these with a little bit more detail and explain how you can get past them, or avoid them altogether.
Trap 1: Difficulty in modifying the default styling
When applying Foundation classes to your project, you will automatically be applying their default styles. This is great for base styles, but can be a little tedious at times when you want to implement your own. As a newcomer to frameworks I quickly found that if not customised enough, it can also leave your site having a familiar look and feel to a lot of other websites that keep the stock standard styles, which of course the designers will resent. I felt that at the beginning, I didn’t know where to start and that I couldn’t break free from the chains of the default styling.
Change the default styles
First of all, I highly recommend using SaSS when using Foundation and If you didn’t know where to start, you should read our step by step Sass and Compass for beginners. I found the quickest way to customise the Foundation basics of your site is to change rules in the _settings.scss file. By uncommenting and making changes you can set your own defaults such as colours and sizing, and it can quickly allow you to step away from Foundation’s norm and start making it your own.
You can also create and import your own files where you can add additional base styles and can quickly make overall changes to your site. I have _global.scss which holds variables that I have created and _general.scss for base rules and styles that will be used throughout the site.
Just remember when importing style sheets, they are Cascading, so list them from highest importance to the lowest. @global.scss should be imported before any other sass file, as it is the most important. If you @import your _global.scss lower down the list, they may be overridden by other rules.
Be more specific
The biggest hair-pulling situation I came across, was when I would set my styles, flick back to my page and see that they had not been applied. After checking back and forth I would come to the realisation that Foundations styles were overriding mine – a time consuming battle. At the start I didn’t fully understand why my styles were not being implemented and I was at times guilty of fighting fire with fire and adding !important to a property, to push my rules to work. Not only is this bad practice, it’s unnecessary.
Once I came to really understand the meaning of CSS, or Cascading Style Sheets , I realised that if my rules were being overridden, I needed to give them a higher priority and/or get more specific. A good rule of thumb for specificity I use is ICE (Id’s, Classes, Elements). Take a look at your code. Can you be more specific by going up a few layers and targeting the parent class or element? Even better, are there unique blocks in your pages that could have an id instead of a class?
Trap 2: Too many divs can cause huge confusions
When I first started to use Foundation’s grid, if I could put my content in a row and column, I would. It actually got to the point where I was putting even small amounts of content into rows and columns. These additional elements not only increased the rendering time, it became harder to find specific elements as my pages became full of divs – lots and lots and lots of divs!
Because they were nested inside one another, I found it increasingly difficult to debug my code. I couldn’t figure out which large-12 or medium-6 the column was referring to, and the page would often break the normal grids when the browser was being resized. Here is what I did to overcome these issues.
Proper indentation & commenting for readability
Even as a beginner, you should be correctly indenting your HTML for ease of readability. But no matter how many divs you have or how big your code is, it’s a very good idea to add comments to distinguish your code.
This is helpful for others that may need to modify or review your work, and believe me it’s great for your future self for when you need to return to your code!
<div class="row"> <!-- Content container --> <div class="large-8 medium-8 columns"> <!-- Main content --> <h5>Here’s your basic grid:</h5> <div class="row"> <div class="large-12 columns"> <div class="callout panel">
</form> <!-- End of example form --> </div> <!-- End of main content --> <div class="large-4 medium-4 columns"> <!-- Sidebar --> <h5>Try one of these buttons:</h5> <p><a href="#" class="small button">Simple Button</a><br/> <a href="#" class="small radius button">Radius Button</a><br/> <a href="#" class="small round button">Round Button</a><br/> <a href="#" class="medium success button">Success Btn</a><br/> <a href="#" class="medium alert button">Alert Btn</a><br/> <a href="#" class="medium secondary button">Secondary Btn</a></p> <div class="panel"> <h5>So many components, girl!</h5> <p>A whole kitchen sink of goodies comes with Foundation. Checkout the docs to see them all, along with details on making them your own.</p> <a href="http://foundation.zurb.com/docs/" class="small button">Go to Found ation Docs</a> </div> </div> <!-- End of Sidebar --> </div> <!-- End of content container -->
Avoid too many rows and columns
My other advice is to look at the page you are going to build, and break it down into rows and columns. Use the rows and columns for your basic layout, but not for every little detail. From personal experience, it can be easy to fall into this trap to avoid having to style it yourself.
It can difficult to make changes or target elements with the added styles that the rows and columns come with though. So for semantics and your own sanity, sometimes it’s best to do it yourself. Stick with Foundation’s grid as the skeletal layout but do the rest yourself.
Trap 3: No IE legacy support
ZURB has made it clear that Foundation no longer supported IE8, which is understandable. However, until it is completely removed, it is always good to work towards having your site functional and presentable in IE8.
Now, many web developers will argue that this is not a big issue, but the numbers below speak for themselves:
*Stats from StatCounter
IE 8 marketshare was 5.55% (this translates to 135 million people out of 2.5 billion people who were accessing internet at the time). These 5.55% of internet users mostly consists of traditional businesses such as banks and government agencies, where the upgrading of computers and operating systems often takes years due to security, resource, monetary and bureaucratic constraints.
Many of our previous projects have needed to target a wider audience that were not just aimed at the tech savvy. This included the types of businesses that I’ve mentioned above that prefer to have the same look and feel across different browsers and devices and yes, this often included IE8 or worse, the much dreaded IE 7!
Implementing IE8 browser compatibility can be easier said than done sometimes though! First off, IE8 doesn’t support Media Queries or CSS rem values, so it can cause your site to look very different or even in some cases, unrecognisable on IE8.
Below are some of the methods that we’ve used to get the site looking great in IE8. Also be sure to check out our article on how to solve Foundation’s IE legacy problem for some step by step instructions.
As mentioned above, Media Queries are not supported in IE8, so what that means is that it will display the IE8 desktop site, with the mobile grid layout you set. To fix this, you can use respond.js, a polyfill for CSS3 media queries. You can download it from GitHub. It’s super quick and easy to use, and will make an immediate difference to your IE8 rendering.
Here is a step by step guide to get around the padding and margin issues that occur with using REM values, since rem units are not supported in IE8 Create a Sass stylesheet entirely for fixing legacy browsers which don’t support rems.
1. Create _legacy.scss in your scss folder, import into your main Sass stylesheet
// File: main.scss // Legacy browser fixes @import "legacy";
2. Get a custom build of Modernizr, make sure you tick css-remunit under ‘Non-code defects’. Import the Modernizr script in your <head>, before the stylesheets are loaded
3. Add the pixel/em value overrides for the Foundation components which you are using. Embed inside the .no-cssremunit selector to target browsers which don’t support rem units.
- Rem values are still available for modern browsers
- Will support any browsers which lack rem support
- No need to hack any of Foundation’s files
- Requires extra CSS to be generated
Other IE styles
The above will fix the main layout issues with your site in IE8 but there may be a few other little cosmetic changes that need to be made. You can do this by putting any additional style changes into a separate _ie.scss file.