The release of Centurion is just around the corner and with so many loose ends to finish up before then I wanted to sit down for a minute to remember why I built Centurion in the first place.

Centurion was originally built for my own web projects, whether they were personal or for a client, I had created Centurion to prevent myself from rebuilding styles, semantics, and various other little pieces over and over again. For a web designer it’s hard to rebuild structure into diverse degree of web projects. At first each one uses a different layout, different styles, and will look visually distinct from the last project you worked on. Having worked with so many small design shops in the past I found this at the time to be a true and known factor to working on the web. “You will have to build it again, differently this time.”

Over the years and working on so many different projects I noticed patterns and structure similarities starting to unfold. For an individual web designer their code will take on a similar structure as they adopt shortcuts and unique was to structure their own code, however, when you start seeing other designers work with the same basic elements as well it becomes harder to avoid. There is a pattern and order to the web.

That was the moment Centurion was born, or at least conceived. The first project I used it on was for a responsive design, so if you decide to take the time to read through my code base on Github you will notice that responsive is at the core what Centurion was originally meant for.

At the Core

From that initial spark of code it grew and new features were added into the framework, such as, color schemes, buttons, tables, navigation and so on. The first two releases of Centurion, which have been kept under the radar had many of the same directions built-in and were entirely controlled by JavaScript to switch stylesheets based on screen size. I found this to be excessive use of code and then immediately ditched the direction version 2 was going (after very little discussion). That’s when Centurion used media queries and never looked back.

Centurion 3 embraces media queries much more so than any other release of the framework, which have all been deprecated in order to move more people to think about modern browsers. While my general distain for IE exists, I thought, “I should at least make the basics of Centurion work” and they do. While most of the responsive framework does not respond in IE; the grid and many other components all work in IE making it a win in my book.


Centurion v.3 has a certain level of complexity, which can make it hard to understand what is going on. You will see that Centurion is compiled into one neat, clean stylesheet. This fact is made possible using Sass, which allows for “Syntactically Awesome Stylesheets”. A version of Centurion using Sass is available on Github as well if you are interested. I cannot even begin to imagine how much time I have spent trying to keep track every element in a three-thousand line CSS document. You have probably seen worse, but like me have blocked out those memories. Well to be honest it can be hard to keep track of what is doing what and where to add an addition to a stylesheet of that nature. Everything is left aligned or indented in an attempt to keep track. However, what if your stylesheets could look one way for the browser, but be written differently for the developer/designer to keep track of and that is where Sass enters the arena. Read more about Sass and building better stylesheets,

Documentation Coming

The last few pieces is the documentation, which I have wrangled a few of my fellow developers in the community to help build for a robust guide to using Centurion for anything to do with responsive design.

Documentation: Centurion Repo: