Patterns, breakfast of champions

Creating a website these days is a piece of cake, as simple as a bowl of cereal. It really is. A custom built enterprise behemoth of a web application, however, is a completely different kettle of fish. Each seemingly innocuous decision you make impacts the next and eventually becomes an avalanche of shortsightedness that kills you and the entire village. So, if you’re (un)fortunate enough to be involved a such a large project, watch your step. Getting the basics right might just save you and your kin.

FE-Patterns

Now don’t go thinking I’m being hysterical, I’ve seen the carnage with my own eyes. Large web apps are an exercise in continuous change. Change in scope, change in marketing, change in tools, technology, budget, people (aka resources) etc. etc.

What you, as a front-end developer, want need is HTML to be resistant to change. CSS and JavaScript are such a needy pair that they want HTML to bend to their will. Changing HTML, it turns out, is costly because it hooks into everything. This includes the back-end, who happens to be a bit of bully.

Making a durable and maintainable web site can really be less painless than it usually is. The trick to it is not to pretend that the web stack is a single entity. It’s three technologies that need to work in parallel and should therefore avoid tripping each other up. The first step is by being generic or agnostic when technologies intertwine and are allowed to be specific when they operate within their own domain.

Structural patterns

Generic: HTML & JavaScript:

<script src="init.js"></script>

Specific: JavaScript:

require(['jquery','jquery-ui','validation'],function(){ … });

Generic: HTML & CSS:

<link href="main.css" />

Specific: CSS:

@import ../normalize.css;
@import ../forms.css;

Preprocessors are well suited for this type of concatenation

Changes are now less likely to occur in HTML because the ‘expert’ can make the needed changes in their own little patch of the app. (This opens up a whole other can of worms but I’ll leave that for a future blog post)

OO CSS and the more recent SMACSS are methodologies that help you with markup structure because large scalable web site need to be robust and simple so that they can cope with the strain of growth and change. Getting this right is very important as there is little room to manoeuvre.

The upside is that the level of front-end knowledge has improved over the years and the need for the restrictive and semantically awkward OO CSS has lessened. HTML5, CSS3, preprocessors and dependency loaders have made it considerably easier to create a stable web stack foundation. SMACSS which takes the current state of the web into account is easier and less abrasive to implement.

Nil Pattern

Resets look like a gift from god. Getting all your browsers to behave and be equal sounds to good to be true, and you’d be right. Resets are overkill and actually end up needing more work then they’re worth. This is where patterns really start to be useful. Take a reset, remove the parts that are already covered by browser conventions and apply them with properties and values you will actually use and need. Having everything set to zero make no sense. Removing the padding/margin on a paragraph and then putting it back is redundant or worse, forgetting to set it at all would be considered negligent. Set your basics like fonts and headings from the beginning because you’ll be using them all over your site. Do it now so you won’t have to remember to do it later.

Browsers that do it differently are on their way out (waves to IE6/7) and this makes zeroing out your CSS a little nuts. The more sensible approach like normalize.css 1) will likely prove more useful over time.

Content patterns

Id attributes are a pain because everybody wants in on them and nobody wants to share. The back-end boys want them so they can tell JavaScript where to append there logic output. Even though it’s tempting you can’t use these ID’s for your CSS because they’re not under your control 2). This is something you’ll keep running into. Not relying so heavily on ID’s will keep you from spending your energy and goodwill on markup conflicts.

Classnames suffer from similar issues but tend to be less contentious. Especially when you exchange your nasty camelBacked ID hostage for a nice semantic classname. The more semantic nature of HTML5 brings welcome relief as we can forgo the classnames that overlap with the new tags and thus reduce the specificity of css selectors.

Content specific attribute like ‘dataGridProgressBar’ are bad. They’re as bad as using presentational attributes like:

.blue { color: blue; }

Ever meet a designer that never changed their mind? No, neither have I. You don’t want have to change both the selector as the property value and the classname in the HTML.

It’s surprisingly easy to have generic markup patterns for Web forms. Extending these with app specific rules is then pretty strait forward.

<form id="sendToBackEnd" class="module log-in">
  <fieldset>
    <div>
      <label for="email">E-mail</label>
      <input id="email" type="email" placeholder="email address" />
    </div>
    <div>
      <label for="password">Password</label>
      <input id="password" type="password" placeholder="password" />
    </div>
  </fieldset>
  <div class="buttons">
    <button type="submit">log in</button>
  </div>
</form>

What’s with all those <div>’s I hear you cry. They in semantic way group the label and input pairs but more importantly they provide hooks for the CSS wizards to do their magic without having to interfere with the markup. You’re gonna have to fight consult with the back-enders about validation anyway so let’s not pile it on. The HTML is going to grow and patterns help you reduce complexity. Growth is inevitable and Jens Meiert says it best: Get the HTML right.

I’ve avoided the semantics discussion, it’s all been said before.

DRY

Patterns are only useful when they’re documented and shared. Comments in your code are hardly documentation and not very suitable for documenting patterns. It just leads to discussion to what to author meant when it’s entirely possible that even the author doesn’t remember.

From the get go determine the basic patterns you’ll likely need for your project and share them. This is collective knowledge that you won’t need to rehash because everybody has an opinion what the markup for sign up form should look like. Repeating yourself is a huge waste of time. Tip: Jeremy Keith’s Pattern Primer.

Custom patterns

With some basic patterns locked and loaded it’s time to get serious with some custom patterns. This is usually where the wheels come off so be careful. Everybody likes new and shiny toys and so we tend to give that new property a whirl. Some end up with this try-and-refresh-browser technique (if you can call it that) and are asking for trouble. Avoid doing this in production code and if you do, like in a branch for example, for God’s sake remove all of it if it doesn’t work. If you lose your way SMACSS can bring back some sanity. In any case limit everything, limit your HTML, CSS and selector length. Specificity kills!

To do this you’ll probably need to do some refactoring from time to time and at least the following:

This is just the start and remember that patterns are the best way to start a project. It will help it grow into a young strong champion.

So what are you waiting for? Start your next project with one of the aforementioned libraries or better yet, build your own!

1) normalize.css contains some browser specific hacks so I can’t wholeheartedly recommend it. However, it does contain a mountain of useful information so be sure to give it a look see.

2) Older web frameworks like JSF and .ASP.NET are the worst. Even the back-end boys have limited control with these systems.

Note: This article was originally posted on Fronteers and been translated into English for this blog.

Next entry: The Web Devided
Previous entry: $CSS