I needed a CSS framework that worked slightly differently from those available - so I built my own.
I did it my way
Melody was borne out of frustration with the available CSS frameworks at the time. I was jumping between frameworks the second a new one came out. Why? Because the ones I was using didn’t really meet my needs, they all involved compromises. I needed something incredibly easy to use; flexible enough to encourage rapid prototyping, yet robust enough to use as production code.
When I first built Melody in 2012, it was one of the first frameworks to drop support for IE7 and below, and use display: inline-block; for arranging grid elements, rather than floating them. It used padding and box-sizing: border-box; instead of margin for gutters, to allow grids to be nested. The whole CSS file was just 8kb, yet still managed to include a reset, the typographic foundation, and a full CSS grid system.
It became the foundation of all my client development work for the next two years, as well as being used by developers all over the world. Here’s the site as it was when Melody was released:
As time went on, my skills and experience broadened, and I began experimenting with SASS and Gulp. For a time, I used the original melody.css as a base stylesheet, and used SASS to build site-specific styles on top of this. However I soon grew tired of the disconnect, and decided to rebuild Melody from the ground up; less as a grid system, but as a full SASS layout engine, keeping true to the principles on which I built the original.
One thing that I did want to improve on, was that the original Melody was heavily dependent on classes in the markup. In this new version, I wanted to go one step further, and do as much of the layout work autonomously as possible, without dirtying my markup. The new layout functions require only a single SASS mixin to be applied to the parent, allowing the framework to do the rest for you.
With the increased flexibility of this new version, there is of course more complications, and so I have also developed a new site, containing in-depth documentation of all of Melody’s features.
I’m using an early version of this new framework on this site, and I’m continuing to develop it as I use it on both personal and client projects.
NOTE: I wrote in more depth about my reasons for building the framework in an article on Everyday Designer.
Headings
JAF Bernino Sans Bold
Subheadings
FF Meta Serif Bold
Body
FF Meta Serif Book
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Error, eligendi, odio, alias, voluptatibus repellendus obcaecati accusantium asperiores id ab exercitationem nostrum illo veritatis molestiae. Ipsam, voluptatibus dolor laborum consectetur recusandae.
The Finished Product
What I Learned
code shouldn’t be invasive
A framework shouldn’t interfere with the code of the app or site that’s built on it. If you’re having to modify a framework to get it to work for you, or implement hacks to override portions of it, you’d be better off not using a framework in the first place. Developers are a fussy bunch and if your code is not up to scratch, they’ll tell you.
good things come in small packages
I tried to do as much as possible with as little code as possible. The first version of Melody was just 8kb before minification. The new version is even smaller. The small file size makes a huge difference when you’re serving content over a slow connection.