HTML & CSS
Article

Semantic Markup with Foundation 5 and Sass

By George Martsoukos

In one of my previous articles, I compared the grid systems of both Foundation 5 and Bootstrap 3.

This time however, I’ll go beyond the basics of Foundation’s grid structure. That being said, I’ll show you how to create more semantic grids by taking advantage of its pre-built Sass mixins. To demonstrate it, I’ll reconstruct the demo page of the aforementioned article. But first, let me introduce the project that will be used for this article.

Project Structure

Using Foundation’s Command Line Interface, I set up a Compass project. Its structure can be shown below:

asss

Keep an eye on the following folders:

Folder Name Description
foundation Contains all Foundation’s assets (css, scss partials, js).
scss Contains the files you can use to customize Foundation.
stylesheets Contains the output CSS file.

The app.scss file determines the components that our project will include. By default, all of them are imported. However, in our case we select to import four of them. That happens because we’re only interested in using mixins that are located in three partial files (_block-grid.scss, _grid.scss, _buttons.scss). Moreover, we want to maintain Foundation’s typographic styles and hence we also import the _type.scss partial.

In addition to the predefined components, the app.scss file can contain as well custom styles. Here’s the structure of our file:

Screen-Shot-2015-03-01-at-15.18.44

Below is the path to the custom partial:

Screen-Shot-2015-03-01-at-15.17.00

Furthermore, we have to limit the output CSS (reduce its size). In fact, we want the app.css file to include only Foundation’s typographic styles and our custom ones. For this reason, we set the following variable values to false:

  • include-html-grid-classes
  • include-html-block-grid-classes
  • include-html-button-classes

We can change their values in the _settings.scss partial file:

Screen-Shot-2015-03-01-at-14.44.31

Last but not least, all the files of this project can be found here.

Let’s continue by covering three of Foundation’s core mixins. Please, keep in mind that examples of those mixins are available in a second project. Here’s how it looks like:

Screen-Shot-2015-03-02-at-22.13.58

Rows

The grid-row mixin allows you to define the rows of your grid. Below is its parameter:

Parameter Description Default Value
behavior Adjusts the width of the row and/or the nested row. false

And here are the possible values of this parameter:

Values Description
false Use this option when you want to wrap your columns inside a row. This will give it a max-width property value. Moreover, it’ll set its margin-left and margin-right property values to auto.
collapse Use this option when you want to wrap your columns inside a row. This will give it a max-width property value. Moreover, it’ll set all its margins to 0.
nest Use this option when you want to create a nested row. This will give it a negative margin-left and a negative margin-right property values.
nest-collapse Use this option when you want to create a nested row. This will set all its margins to 0.

Columns

The grid-column mixin generates your columns. The following table shows its parameters:

Parameter Description Default Value
columns The number of desired columns. false
last-column Is this the last column? false
center Center these columns? false
offset The number of columns to offset. false
push The number of columns to push. false
pull The number of columns to pull. false
collapse Remove the column padding? false
float Float this column? true
position The positioning type. false

Block Grid

In case you want to take advantage of the block grid, Foundation provides the block-grid mixin. Here are its parameters:

Value Description Default Value
per-row The number of items to display per row. false
spacing The number of ems to use as padding on each block item. 0.625rem
include-spacing Adds padding to the list item. true
base-style Applies a base style to block grid. true

Putting It All Together

At this point, hopefully, we’re ready to create our demo page.

In the following screenshot, you can have a look at the desired layout for one of our sections:

ff

Based on the viewport width, we make the following assumptions:

Window width Description
≤640px Each article covers the full width of their parent container.
Between 641px and 1024px Set the value of the columns parameter to 6. That means, each article covers 50% of their container’s width.
≥1025px Set the value of the columns parameter to 3. That means, each article covers 25% of their container’s width.

Here’s the relevant HTML:

<section class="services">
    <h2>What we can do for you</h2>
    <article>
        <div>
            <i class="fa fa-bar-chart fa-4x"></i>
            <h4>Statistics</h4>
            <p>
                <!-- content -->
            </p>
            <a href="#">Learn more</a>
        </div>
    </article>
    <article>
        <!-- content -->
    </article>
    <article>
        <!-- content -->
    </article>
    <article>
        <!-- content -->
    </article>
</section>

Our Sass code:

.services {
    @include grid-row;

    article {
        @include grid-column(12);

        @media #{$medium-up} {
            @include grid-column(6);
        }

        @media #{$large-up} {
            @include grid-column(3);
        }
    }
}

And the resulting CSS:

.services {
    width: 100%;
    margin-left: auto;
    margin-right: auto;
    max-width: 62.5rem;
}

.services article {
    padding-left: 0.9375rem;
    padding-right: 0.9375rem;
    width: 100%;
    float: left;
}

@media only screen and (min-width: 40.063em) {
    .services article {
        width: 50%;
        float: left;
    }
}

@media only screen and (min-width: 64.063em) {
    .services article {
        width: 25%;
        float: left;
    }
}

Note: To keep things simple, I’ve only included some of the rules from the compiled CSS. If you want to see the complete CSS that Foundation outputs, take a look at the app.css file.

In the same way, let’s continue with our second example. Below are the styles we want to apply to the footer element:

Footer

Again, we structure it by taking into account some assumptions:

Window width Description
≤640px Each div element covers the full width of their parent container.
≥641px Set the value of the columns parameter to 4. That means, each div element covers around 33.33% of their container’s width.

Furthermore, we take advantage of the block-grid mixin to include the nested row in the last div element.

The HTML code can be shown below:

<footer>
    <section>
        <div>
            <h4>About Us</h4>
            <!-- content -->
        </div>
        <div>
            <h4>Our Mission</h4>
            <!-- content -->
        </div>
        <div>
            <h4>Find Us</h4>
            <ul>
                <!-- content -->
            </ul>
        </div>
    <section>
</footer>

Here’s our Sass code:

footer {
    section {
        @include grid-row;

        div {
            @include grid-column(12);

            @media #{$medium-up} {
                @include grid-column(4);
            }
        }

        ul {
            @include block-grid(2);
        }
    }
}

And the compiled CSS:

footer section {
    width: 100%;
    margin-left: auto;
    margin-right: auto;
    max-width: 62.5rem;
}

footer section div {
    padding-left: 0.9375rem;
    padding-right: 0.9375rem;
    width: 100%;
    float: left;
}

footer ul > li {
    float: left;
    width: 50%;
    padding: 0 0.625rem 1.25rem;
    list-style: none;
}

@media only screen and (min-width: 40.063em) {
    footer section div {
        width: 33.33333%;
        float: left;
    }
}

Note: Again, for simplicity, I’ve only included some of the rules from the compiled CSS. To see the complete CSS that Foundation outputs, look at the app.css file.

Conclusion

In this article, I presented to you three Foundation’s mixins you can use to deliver cleaner and more semantic HTML code. As a next step, I encourage you to dive into its Sass files and examine all of the mixins (46 with the current version). Thankfully, the documentation is really pretty good, so I hope you’ll not have any problem understanding them! In this way, you’ll have the opportunity to combine the power features of this framework alongside with your own customizations.

Free Guide:

7 Habits of Successful CTOs

"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.

Comments
bluedreamer

Good read!

I still think it's a lot of faffing around using these frameworks when you can write lean, mean CSS by hand.

RyanReese

THANK YOU.

sturobson

Maintaining CSS can be a faff too, whether written by hand on paper or typed into a computer, right?

bluedreamer

That really depends how well its been written and structured?

sturobson

Good quality front-end web development in general depnds on the how well it's written, structured or maintained. Badly written CSS is badly written CSS. Writing bad code in a preprocessor writes bad CSS to which both create a faff. So in that, both rolling your own code (as I do) or choosing to use a framework, as used in this article, can be a faff.
I guess the question is, how could this article have helped make using a framework seem not look like a faff? Anything constructive is always greatly received.

oddz

For a single person perhaps. However, when many hands are touching a project it is better to have some type of framework in place so that there can be some level of enforcing continuity and less of a dependence on a single individual. Not to mention many frameworks come with documentation and I can't remember the last time I saw any documentation from a front-end developer. Furthermore, I would argue that if you haven't found many bugs with your custom code that you haven't been looking hard enough. Many of the popular open source solutions while not perfect are constantly being put to the test thus finding bugs, edge cases consequently fixes for things that would probably be overlooked by a single person working in isolation. I would also argue against myself to the fact that is far more important with server-side code than it is with front-end, css but I still definitely believe css frameworks provide the same general advantages as server-side ones. Like I said in a previous post on an unrelated topic I think those people who don't like to use frameworks are merely to afraid to try something new as they are stuck in their old ways and stubborn. It is easy to write your own CSS by hand it is much more difficult to use other peoples code knowing enough about it to bend it to your will when the need calls for it. For these reasons I think using a framework so long as you're not just using it as a crutch makes you more a professional and expert than those who neglect these technologies.

oddz

It is good to highlight how to use these frameworks without relying on the special class names. The primary gripe I have had with most css frameworks is their reliance on classes. Which is one reason I have always preferred susy over bootstrap, foundation, etc.

azzcatdesign

This is awesome! And I've been doing it wrong. Hate putting spans or columns markup in HTML. In fact, I've preferred Bourbon Neat over Foundation (and most especially over Bootstrap) just because the grid markup was completely in the Sass files. Guess I never fully understood how to use the mixins with Foundation's grid.

Thanks for the great explanation!

georgemarts

Thanks! Now you learned it smile

Recommended
Sponsors
Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Front-end, once a week, for free.