This post is part of a new series called “Conversations at Caxy,” where we profile our team on new skills and tools they are learning about. Today, we talk to Beck Kramer, Front End Developer here at Caxy. We talked about how to simplify your code process through KSS Style Guides.
Q. What does KSS stand for?
KSS stands for Knyle Style Sheets. Created by Kyle Neath, it is intended to help you make working, living style guides.
Q. You mentioned that KSS is a solution to some of the challenges to CSS right now. Can you talk to us more about those challenges?
With big sites and any sites that you have multiple people touching as devs, you have issues with restyling the same thing multiple times and not even realizing it. One button might need to look differently somewhere else, and then next thing you know you have 18 rules for CSS buttons. Some of it is, “how does this get introduced?”, “what can you do to stem that?”, etc.
Depending on the pace of the project, or if you are inheriting, it changes midstream, that is when a lot of that stuff is getting introduced, then you have to react to it. So, how can you mitigate that? You have to be able to identify patterns early and get them in place any time structure is needed. Some of it is realizing what a pattern is and recognizing them in your design, and getting that structure ready early on.
Q. Give me an example of a time when you have had this happen.
An example for me would be working on giant sites where you have two teams working on two different areas of the site. Two teams make two patterns, that look the same, but one side’s looks a certain way, then the other makes one for what they need. Now, you have two css sets that aren’t aware of each other and are aggressively overwriting each other versus unifying them.
Q. KSS is a means to manage this. Are there any other tools that help?
A good thing to do is identify patterns early in the process and break things down into chunks of work. KSS helps you break it down and make a living style guide. You know what you are working with and what you can extend upon.
Q. So, where does it live in the repo?
You can set it to populate in a directory. In a Drupal site for example, you can have it live with your theme files with everything off to the side, so it could just be up there. So what happens is the version you're using is compiling with node, it takes some backbone templates and takes your css and populates a set of HTML files based on the templates, based off what if finds in the CSS. We have had some success with the Git repo rendering itself, so that way you can merge master into another branch that you can show to the client quickly. If we wanted it to be something that is more difficult to get to (password protected) you can do that as well.
Q. What do developers need to know to be able to use it?
Ideally, the process would go: there’s a new pattern or change, it goes to the style guide first, then to the production site. For example, if we decide the red button will be blue, changing it in the Style guide will show up properly on the site.
You can also use a very basic versioning system that goes with a sprint version, in terms of looking at the same version as the client.
Q. Where can people go to learn more?
This is a great tool for learning more about KSS: http://warpspire.com/kss/styleguides/.
