#foundation 4

Semantics, HTML5 and Frameworks

Grid-based CSS frameworks, in general, force you to mess up your mark-up with bad semantics. How many times have you had to mark-up a simple container and sidebar like this:

Content

My Content

Sidebar

My Sidebar

Here we've set a fluid container to wrap around two columns, 10 columns wide and 2 columns wide respectively, in our 12 column-wide row. Thankfully, with HTML5, we have pretty block level elements that make our mark-up more meaningful (i.e. semantic):

Content

My Content

Sidebar

My Sidebar

Now our mark-up makes better sense. Things get even simpler (and more meaningful) when we factor in the use of ARIA roles, which can be styled with CSS just like any other element. Plus, now we don't need to use compound classes:

Content

My Content

Sidebar

My Sidebar

Aria roles are easily styled in CSS using the following syntax:

div[role=content] { /* Super styles here */ }

Be careful not to overuse ARIA roles; when to use them is as important as using them properly. Check out this article by the Pacilio Group for more information on that.

So what about those annoying class names used to specify our grid layout of columns and rows? Granted, they're perfectly legal, but do they really add any more meaning?

If any part of the grid had to change, those changes would need to be made across several template files. If your site/application only uses one or two templates, then there isn't much of a problem, for now. There may come a time when you need to add further templates, so at some point it is possible (perhaps even likely) going to be something to consider.

Wouldn't it make sense to be able to make changes to the layout without having to tinker around with class names in the mark-up?

Foundation 4 and Cleaner Mark-up

Whenever I work on a project, I want to do as much as possible to ensure that should anything change in the future, it can be done quickly with the least amount of effort. Good for me, good for client.

The Foundation 4 Framework doesn't force you to use class names to specify your grid layout (although you can if that's the way you role). Consider this two-column layout using Foundation's grid class names:

Content

My Content

Sidebar

My Sidebar

Foundation is a mobile-first approach, so here our main article and sidebar sit underneath one another spanning all 12 columns in our 12-column grid row. As the screen gets larger, the article and sidebar are floated next to each other taking up 10 columns and 2 columns respectively.

Here's how our mark-up could look if we didn't need to use grid class names:

Content

My Content

Sidebar

My Sidebar

Ahh. Deep sighs of coded bliss. So how do we apply the grid now?

Using Foundation 4 SASS Mixins

You can use almost any framework using plain old vanilla CSS but if you want to get serious SASS is the way forward in my opinion. The reasons for using SASS and how to use it are beyond the scope of this article, so if you're not already using SASS here's a good primer.

Foundation 4 has all the grid magic inside foundation/components/_grid-5.scss (or _grid.scss if you're using less than version 4.3).

Here you'll find all the mixins for the grid, a few neat tricks for calculating column widths and all the necessary grid classes.

Using the mixins we can specify our layout right inside our own SASS files like this:

div[role=content] { @include grid-row; // Row container article[role=main] { @include grid-column(12); // 12 Columns } > aside { @include grid-column(12); // 12 Columns } }

This takes care of our row/columns for our default layout, i.e. mobile. To factor in larger screen sizes simply specify the break-point, and the new column size:

div[role=content] { @include grid-row; // Row container article[role=main] { @include grid-column(12); // 12 Columns } > aside { @include grid-column(12); // 12 Columns } @media #{$small} { // Screen is at least 768px wide article[role=main] { @include grid-column(10); // 10 Columns } > aside { @include grid-column(2); // 2 Columns } } }

Now we've taken care of the layout for larger screen sizes. However, there's a problem. By using the grid-column mixin at our 768px breakpoint, we've included all of the CSS again from the grid-column() mixin which bloats the resulting CSS unnecessarily. All we needed was to specify a different column width. We can do this by using the built-in gridCalc() function instead, like this:

div[role=content] { @include grid-row; // Row container article[role=main] { @include grid-column(12); // 12 Columns } > aside { @include grid-column(12); // 12 Columns } @media #{$small} { // Screen is at least 768px wide article[role=main] { width: gridCalc(10, $total-columns); // 10 Columns } > aside { width: gridCalc(2, $total-columns); // 2 Columns } } }

And just for fun, a centered column example that looks great at 8 columns wide on mobile, but too big for tablets and desktop devices so needs to be about half the width:

section { @include grid-column(8, $center:true, $float:false); @media #{$small} { width: gridCalc(4, $total-columns); float: left !important; } }

Now, when the client comes to you asking to make the sidebar a little wider, all you need do is alter your SASS file instead of finding and replacing dozens of class names.

Some Pro's and Con's

So we've got rid of our meaningless grid class names and kept everything super neat and tidy in our HTML5 mark-up. That's a (very) good thing. Code is easier to read, maintain, and makes more SEO sense. The cost is two-fold however.

Firstly, it can lead to more CSS. Declaring columns and rows on every element that needs to be a column or row will likely result in more lines of CSS. This can be limited if you're careful with how you write your SASS and keep things organised. Secondly, you can end up repeating yourself quite easily. However, we're only concerned with the mark-up that controls our layout structure here. There aren't (or at least shouldn't be) a great deal of elements or dividers that need column and rows applying to them.

Foundation 4 allows you to "switch off" the class names for the grid (or any other component you're not using class names for) so you save at least a good couple of hundred lines of CSS code by doing that just for the grid. I say the pay-off out-weighs the cost, especially seeing as the cost is so small. Without all the class names, you're likely saving more lines of CSS code then you're generating.

Further Reading