I’ve been using grid systems in some way shape or form for the past 3 years. From 960.gs, the 1kb grid and 1140, to fully-fledged frameworks like Bootstrap and inuit.css.

They were (are) excellent tools for quickly knocking together sturdy layouts. However each project is different, and — especially with responsive builds — each layout comes with its own nuances.

I’m not keen on using front end frameworks as a one-stop solution, preferring to pull together certain libraries to do one thing and do it well. This is what led me to create the layout system that we currently use as the basis for our bigger projects at Studio-40: MatryoSass (Matryo for short).

After some thought, the needs for our grid system boiled down to:

• Sass based
• Responsive, with IE8 support
• (Infinitely) Nestable
• Fractional, none of this span-12 malarkey
• 5 base widths for media queries
• Easily customisable per project

Semantic vs presentational

The first major decision to be made was whether it was to be semantic or presentational. In short, semantic means that additional <div>s are not used to form layout, the grid styles are applied directly to (semantic) HTML elements or classes, leading to less markup and no presentational grid-col-esque class names. Presentational is the opposite; layouts are formed by a collection of grid and column classes which act as an additional layer around the content and/or semantic elements (nav, aside, article).

I decided on presentational. I’m a firm believer in separation of concerns, and keeping the layout away from the content made a lot of sense. I also find being able to glance at the markup and get a very real idea of what should be happening on the screen incredibly useful. Almost invaluable.

Take the following examples, although the semantic version may look cleaner, I have no idea what the expected layout should be.

<!-- Semantic -->
<!-- No idea on layout, could be block, inline, a mixture of both -->
<nav>
    <menu>
        <li><a href="/">Home</a>
    </menu>
</nav>
<article>
    <h1>Title</h1>
    <p>...</p>
</article>
<aside>
    ...
</aside>

<!-- Presentational -->
<!-- A quick glance and we know it's a 3-column layout,
in the form of [25%][ 50% ][25%] -->
<div class="grid">
    <div class="grid__col 1/4">
        <nav>
            <menu>
                <li><a href="/">Home</a>
            </menu>
        </nav>
    </div>
    <div class="grid__col 1/2">
        <article>
            <h1>Title</h1>
            <p>...</p>
        </article>
    </div>
    <div class="grid__col 1/4">
        <aside>
            ...
        </aside>
    </div>
</div>

It’s not everyone’s cup of tea, but it works for us.

We’d previously been enforcing this rule when using inuit.css, and the “don’t add additional styles to the grid layout” is a simple and effective methodology to apply across projects.

A lot of the projects we do involve splitting up our HTML into partial files. If this is the case for you or your team, I strongly recommend the presentational grid approach. We have a loose rule that no grid styles are in the partial files. These partials are width agnostic components that can be included from within any column size. Here’s an example from a recent Symfony2 project, using Twig files:

<div class="grid">
    {# Footer Column #}
    <div class="grid__col 1/3 sm-1/2 xs-1">
        {% include 'S40ProjectBundle:Frontend/Footer:_nav-pages.html.twig' %}
    </div>

    {# Footer Column #}
    <div class="grid__col 1/3 sm-1/2 xs-1">
        {% include 'S40ProjectBundle:Frontend/Footer:_nav-support.html.twig' %}
    </div>

    {# Footer Column #}
    <div class="grid__col 1/3 sm-1/2 xs-1">
        {% include 'S40ProjectBundle:Frontend/Footer:_nav-legal.html.twig' %}
    </div>
</div>

This separation of components and grid layout partners really well with the concept and mindset of using partials.

Fractional

You’ve probably noticed that the grid class names we’re using are - quite literally - the fractional width we want. One of the major gripes I’ve had with other grid systems is this need to force 12-column layouts onto you whether you need it or not. Why write span-4 when you mean 1/3? Since when does col-9 mean 3/4?

Why should we be constrained by making everything have to add up to 12? It prevents you from using things like fifths, sevenths, eighths, and tenths (etc). What if you want a 3 column layout divided as 3/8ths, 4/8ths and 1/8th? Nope.

The answer was to use fractions as the class names. There was some consideration on my part on making them verbose written names, e.g. one-quarter, or even dashed like 1-4, but I was all aboard the fractional train and believed it would aid readability and keep class name collections to a sensible length.

Bit of a snag, the / character in CSS needs to be escaped. Thus our selector would end up looking like .3\/4 { width: 75%; }. It worked, but a better solution was to be had using attribute selectors: [class~='3/4'] { ... }. Same specificity, same result, more readable selector.

Notice the tilde in the attribute selector? It makes a big difference! It even helped out Harry Roberts on the newest inuitcss.

Responsive

A lot of the frameworks or grids we’d used previously came with 3 defined breakpoints, usually ‘phone’, ‘tablet’, and ‘desktop’ (or something of that ilk). We never found this to be enough, the gaps between them were too large and it didn’t offer enough flexibility.

Five seemed to be the magic number; loosely translating to ‘very small’, ‘small’, ‘medium’, ‘large’ and ‘extra large’. The specific widths themselves would differ from project to project — but we always ended up needing around five.

I opted for a top-down max-width approach, this is similar to what the team was used to and slotted nicely into our current workflow. The premise being you assign a base column width, and then adjust the width of that column with namespaced class modifiers that work down through the breakpoints. If we wanted a ⅕ width column which expanded to ⅓ on our medium view, it would look like <div class="grid__col 1/5 md-1/3">.

Customisable; Naming the things

Layouts are always different, and we don’t always need a full twelve or sixteen columns. One of the best things about Matryo is the option to pass it in a number of fractional widths you want created, e.g. $matryo-cols: 12, or a list of fractions you need, e.g. $matryo-cols: 1,2,4,6. This is a great way at the end of the project to get a nice file size reduction. By only using the columns you actually need you strip away all unnecessary classes.

As well as defining the columnal fractions we need, we also define the 5 widths that form the base of our responsive layouts, e.g. $matryo-bp-xs-width: 30em

We also give them a name.

If we want to call our smallest width ‘lil-sebastian’, there’s nothing stopping us: $matryo-bp-xs-name: 'lil-sebastian';

And now we get unbridled joy every time we target our smallest breakpoint:

// using the lil-sebastian named width media query in scss
.horse {
    height: $normal-horse;

    @include media(lil-sebastian) {
        height: $tiny-horse;
    }
}

<!-- using the lil-sebastian named width media query as a grid modifier class -->
<div class="grid">
    <div class="grid__col 1/4 lil-sebastian-1/2">
        ...
    </div>
</div>

Although 5 breakpoints seems to be the norm for us, it’s by no means the rule. That’s why Matryo breakpoints can be disabled if not needed. We may only want 3 breakpoints on a small project, so we disable the ones we don’t want. And — just like with the fractions list — we reduce the file size by not including classes for responsive breakpoints we’re not using.

Perf matters :)

If you’re wondering what all the double underscores are about in the class names, we use the BEM naming convention at Studio-40. That’s a whole different post in itself, but needless to say if BEM isn’t your thing the grid column class names are customisable too. Pretty much everything is.

You can check out the source code, demo and examples if you’re interested in a fully nestable, reversible, responsive, IE8+ layout system. And what’s next for Matryo? Well there’s plans to add in more named media queries, such as between two widths, as well as an option to choose between min and max-width media queries by default.

Mega nav, super nav, dropdown, flyout… whatever. Big desktop navigation. Just catch a corner of it with your cursor and out it comes. Oy.

This can be incredibly frustrating. I’m looking at you John Lewis, Harrods, and Debenhams. Hmm, I’m noticing a trend.

You might just be moving your cursor down the page because, y’know, you want to click something. The fact you happened to go over a menu item on your way there doesn’t mean you want to be stonewalled with an enormous navigation block.

I ran into this same issue in a recent project and opted for a lightweight solution that utilises CSS transitions on opacity, visibility and max-height. And here’s the nice part: by adding in a .25s delay attribute, it doesn’t fire if you were to just brush over it.

/* Sass (SCSS syntax) */
// on hover/focus fade in the auto height on the <ul>
.has_children{
  ...
  ul {
  	height: auto;
    max-height: 0;
  	opacity: 0;
  	visibility: hidden;
  }
  &:hover ul,
  &:focus ul{
    visibility: visible;
    opacity: 1;
    max-height: 500px; /* bigger than it ever needs to be */
    // vendor-prefixed
    transition: .35s ease .25s;
 	}
 }

By setting the max-height to an arbitrary number larger than it ever needs to be, you get the ‘slide down’ effect.

Want something more instant? Toggle between 0 and auto on the height property instead. You could also ditch the fade by removing the opacity.

Need it to ease-in slower/faster, and with more/less delay? Fiddle with the transiton attributes.

There’s loads of combinations and variations to customise it.

Pen? Pen.

See the Pen Delayed hover menu using CSS by Tobias Harison-Denby (@quagliero) on CodePen.

N.B For some reason it doesn’t fire on focus if I tab to it, but it does if you use the Chrome inspector and set the element state to :focus… any ideas?

jQuery is everywhere. Everywhere. And that’s testament to its ease of use and enormous community, but have you ever stopped to consider if you actually need it?

Scrolling image gallery? Most likely jQuery.

DOM traversing? $(‘.probably-like-this’)…

Form validation? You guessed it.

When I started out in web development in 2008, jQuery’s concise syntax and easy toggle, slide and fade methods made it easier to add some pleasing UI features. I say ‘easier’, I still had no idea at the time.

$('#foo').on('click', function() {
	$(this).slideToggle(); /* zomg it moves! */
});

For a lot of folk (including myself) these were the first tentative steps away from the comfort of HTML and CSS.

jQuery was like our childhood security blanket, protecting us from the big bad monster… JavaScript.

It’s time to let go.

A while back I made the conscious decision that I wanted to — properly — understand and learn JavaScript. It was eye-opening, I’d defaulted to jQuery and its vast array of plugins for so long that you forget it’s actually real JS doing the heavy lifting behind the scenes.

Now there are a lot of times when using jQuery (or other libraries) is absolutely required, but it’s at a stage now where jQuery is the defacto tool for stuff that could just be done with a little bit of vanilla JavaScript (gasp!). From what I see on Stack Overflow, 9 times out of 10 the answer to a JavaScript question will have a “You could just use jQuery” answer.

And they’re right, you absolutely could, you could probably write it quicker too; but is it worth downloading an entire 90KB library just to do a few manipulations and interactions? I don’t think so.

// change the text/html of an element with jQuery
$('#foo').html('Oh yeah new text!');

// a native js way
var foo = document.getElementById('bar');
foo.innerHTML = 'Oh yeah new text!';

...

// toggle a class on click with jQuery
$('#bar').on('click', function() {
	$(this).toggleClass('toggled-class');
});

// a native js alternative to toggle a single class
// (now updated to handle existing class)
var foo = document.getElementById('bar');
foo.addEventListener('click', function() {
	var baz = 'toggled-class';
    if (this.className.indexOf(baz) === -1) {
        this.className += ' ' + baz;
    } else {
        this.className = this.className.replace(baz, '');
    }
    // clear some whitespace
    this.className = this.className.replace(/\s+/g, ' ');
});

...

// loop through a list of items with jQuery
$('#bar a').each(function() {
	 $(this)... // do something
});

// native js with a good old fashioned for loop
var foo = document.getElementById('#bar');
var baz = foo.getElementsByTagName('a');

for(var i=0; i < baz.length; i++) {
	baz[i]... // do something
}

These are just a few crude examples, but ask yourself next time: Do I absolutely, positively, need jQuery for this?

Give it up for a week and just use plain ol’ JavaScript. Go on, try it. It’s liberating.