Why It's a Good Idea to Roll Your Own CSS Framework (and Why I Did It)
Why It's a Good Idea to Roll Your Own CSS Framework (and Why I Did It)
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
It might seem backward and a bit annoying with the recent flood of custom CSS frameworks, but it actually makes sense. A lot of CSS frameworks are built for others and include stuff you may never use. For example, how often do you run across the need to have 10 different styles for tables, especially when it comes to prototyping? What about breadcrumbs? Badges? Circular images? Five other JS plugins?
Creating your own CSS framework comes with a purpose and it should not be taken lightly. You’re not here to flush 10 hours down the drain. You’re here to:
- Help yourself by creating a framework that matches more closely your own design style. While Bootstrap is a great base, it’s generic and cannot match your own work well enough.
- Tailor specific CSS to your needs. If you need specific elements (like footers, widgets, comments, feeds, etc.), you’d have to find an appropriate extension with Bootstrap. Roll your own and style your own commonly used web elements.
- Make sure you write as little code between projects as possible, at least while prototyping. Making your own framework is about doing away with custom code, overriding properties and hoping to “play nice” with the CSS framework you downloaded.
I decided to create my own framework and plug into it my distinct style of designing/coding websites. There are a few things I always have to hand-code in frameworks so that's definitely a pain in the ass that I want to remove, and so should you. For example:
- Most CSS frameworks don’t have block-lists. These come in handy for prototyping comments, statuses, and widgets.
- Most CSS frameworks don’t have a concise extension library and any “extensions” end up being hacks.
- Most CSS frameworks don’t have a way to animate elements, not even with a functional class.
- There's no footer anywhere.
In the end, I found that I can easily code up my own framework that fits my view, just like I coded up my own WordPress theme that fit my general development needs and became my “starter theme”.
Note: This solution isn’t for everyone. If you lack the time or motivation or whatever you can easily purchase a Bootstrap theme that matches your tastes closer and work off of that, or customize bootstrap. A good place to look is WrapBootstrap or even ThemeForest (affiliate links).
Introducing the Tseczka CSS Framework (Pre-alpha)
“Pre-alpha” basically means that it may look s****y but I’m pretty proud of it and it’s a good start to roll from. So what does my framework currently include, and why?
The reason I’m discussing my own framework is for you to get an idea of how useful it can be to do this.
A Simple Grid
I used One% CSS Grid for the basis of my grid and am currently working on media queries for it. I added some utility classes to help visualize the grid (i.e., shade them and add height) before any content is added, which is something I was missing before. So why did I use a new grid? Well:
- Every CSS framework needs a grid of some kind, be it from Foundation, Bootstrap or wherever.
- Having a visualization for the grid is very important to me. If I start laying out the grids, I want to be able to see what the “final” result will look like before I add the content.
Typography was something that always bothered me. Every framework tries to tackle it differently, some ending up with headings that change too wildly in size, and some without enough distinction. I’ve also found very ugly blockquotes, etc. So I tried to fix this problem and continuously upgrade this portion of my framework whenever I come up with a neat idea.
- If you dislike the current solution for typography, it’s a good practice to code your own or copy the existing one and fix it up.
- You can easily enforce your own conventions for typography. The standard baseline height is 1.5em. Do you think that some elements should behave under a different baseline height? Do you prefer a 1.75em baseline? Update your framework.
Many CSS Frameworks get judged by the buttons, no joke. Well, the buttons and the nav. So here are mine. I was hoping to create some simple and flat buttons and work off that. I like Bootstrap 3′s new flat design that gets rid of the plastic look and the BS3 look is what I’m hoping for. I’ll be updating this portion substantially since, honestly, this is the part I care for quite a lot but have no idea where to start with.
- While buttons may not seem like the important thing right now, they can have a great impact on prototyping a web app. You can easily make sure you follow your own standard conventions
The nav bar is another part of CSS frameworks that determines the framework’s success. I’m not entirely sold on what I have right now since it’s basically a colored copy of Foundation’s nav bar. However, there are some things I added that I’d like to point out:
- When not extended fully, the nav bar still stays in a rectangular shape and does not gain rounded corners.
- several color options are available including: main color (this reddish/rusty color), secondary (blue), grey, and white. I added these in case I want to use sub-navs, widgets navs, or just navigations elsewhere.
Footer is one of the biggest things missing from most CSS frameworks. And it totally makes sense, just not for my workflow. I’m working on a way to port over my old footer’s design from my Tseczka WordPress theme:
Again, we’re in pre-alpha stages which is why my version looks WAY off. I’m hoping to have a concise way of declaring a footer without making the markup TOO specific so that I could use it elsewhere. I would not like to have a separate typography sheet just to declare it, either.
- Most CSS frameworks don’t include a “footer” element. Footers are important and rolling it into my CSS framework was a big deal.
This is where I solve the meat of my issues. While Bootsnipp for Bootstrap manages to demonstrate how you could build all these things with just bootstrap classes, I feel like it fails to address some of the major points and gets only “very close” to an ideal prototype. This is why I started building prototype-specific extensions. I included a “comments-meta” list class that changes the size of the text, makes the list elements inline, and kills the left-hand margin. Same goes for the feed list and comments. I’m playing around with the feed list which (with comments) will end up resembling Facebook’s statuses and (without comments) Twitter statuses as well. The feed-list is built entirely using lists so you end up having a parent list of feed items, a list for the meta stuff (read more, ignore, etc.), and a list for comments.
Obviously, I haven’t started styling forms so the form looks like crap!
It looks like s**t, how does this even help?
Well, like I said, I’m in the pre-alpha stage where I’m still planning things out and trying stuff out but my goal is pretty clear. I’d like:
- An easily extensible CSS framework
- A CSS framework that includes ALL the major elements I use when building websites (so that it includes a way to build feeds, comments, widgets, etc.)
- A variable system that makes it very quick to change the look of the entire system (just like any other CSS framework)
- Enough classes to allow in-browser design, but not too many classes that it bloats the stylesheet
- Styling simplicity
- Last of all, a non-override nature. I don’t want my framework listed as a dependency and then overridden with YET ANOTHER STYLESHEET! That’s what we have Bootstrap for.
Why the non-overriding nature?
I want Tseczka CSS Framework to be entirely independent of its development. Once you clone the repo, that’s it, it’s yours. You’re welcome to add new features or cherry-pick what you like from the development but the main point should be for a developer to take it as a final product and build onto it on their own by modifying the existing LESS files or the compiled CSS file. I WANT people to dive into it and not use it as a black-box of tools that they only dive into when they need something. I want them to use my framework, in the end, either as vanilla for prototyping or as a skeleton for full development.
This means that Tseczka is not meant to be kept as a dependency via Bower or other similar tools.
What’s the plan for future?
My plan for the future is to create a new extension to my framework whenever the need arises. If I happen to need a better “feed” list, I’ll update it. If I happen to need a Pinterest-like UI, I’ll create an extension for it. I already have a WordPress UI extension in the works, based on my original WP Theme.
You’re welcome to check all this out:
Still not convinced?
That’s fine. Look, my argument is that having your own CSS framework for prototyping is crucial and can lead to a great experience, especially since you can keep standard conventions within your design. Whether you like things minimal, skeumorphic, shadowy, exaggerated, or whatever, you can keep on extending your framework and making your prototypes match your style. Not only will your clients appreciate it (because they’ll see something closer to the finished product) but you will as well.
Published at DZone with permission of Antonin Januska . See the original article here.
Opinions expressed by DZone contributors are their own.