Sass is like Pringles: once you pop, you can’t stop. After using Sass for a couple projects, picking up a vanilla CSS project feels weird. “Where are my variables?” “Why can’t I nest things?” “I just want this one mixin…” In all of our Sass-isfaction, it’s actually pretty easy to forget that there developers out there who don’t or can’t use a preprocessor. And we shouldn’t forget them or disparage them!
There are plenty of situations where you might hand off a site to someone who doesn’t use a preprocessor. Some developers are freshly starting CSS and nailing down that core knowledge. Some love the ideals and simplicity of CSS and feel that a preprocessor adds needless bloat to their workflow. Others maybe working with a limited set of tools and don’t have the ability to run a preprocessor where they need to. I’m not saying these are all ideal or perfect situations, but each one has a measure of validity.
If you’re going to develop in Sass, you may need to have a game plan for how you’ll hand it off to a Sass-less developer. Let’s look at how this process normally happens and try to identify the best way for you to make your end of this hand-off as smooth as possible.
Just hand them the code and walk away.
This is probably the default: we just pass along the code to whoever is going to maintain it and hope for the best. Unfortunately, this may also be the least helpful method.
What happens when we give a client or site manager a folder full of Sass partials and no instructions? I don’t have any empirical evidence to support this statistic, but I’d bet that nine times out of ten, the /sass/ directory is ignored and all changes are made to the compiled CSS. Is that a problem? Well, if you compressed your output, yeah. Good luck to even an experienced CSS author making edits to a compressed style sheet!
If you’re going to deliver code without any preprocessor instructions, you should be prepared to deal with all the client’s edits if they ever ask you to do more work on the site in the future. Be ready to move all their edits back to Sass and resume your workflow, or simply edit the CSS. If there’s even the slightest chance someone will want to use a preprocessor on the site again, I recommend giving the client a quick explanation of your set-up and a warning that any changes they make to the compiled CSS are in danger of being overwritten if a future developer is careless about returning to Sass.
Only deliver the compiled CSS.
If you know that no one will ever use your Sass files again, I wouldn’t bother including them in the deliverables. In some cases, I would also recommend delivering an unminified style sheet for the sake of simpler maintenance. I know this is a performance hit: if that concerns you, talk the client through the pros and cons of performance vs. maintainability and let them take responsibility for the decision. If you’ve got a caching / minifying / concatenation performance tool set up for the delivered site (WP plugin, web service, etc), this is a moot point. Just give them the unminified CSS, let them edit it happily, and let the performance tool handle the minification.
Give them a separate “edits.css” style sheet to put changes in.
I don’t like this idea much. Performance takes a hit because you’re adding another request to the render-blocking critical path. Also, this method accidentally encourages over-specificity. Not everyone understands that later CSS overrides prior CSS if the selectors have the same specificity (I guess for those people, it’s just SS, not CSS?) Someone like that will be prone to filling their edits.css file with !important declarations and unnecessary IDs.
If, however, you’re handing off to a skilled CSS maintainer and they’re comfortable with the slight performance hit (or using a minifying/concatenation plugin to negate it), this is a great way to keep all the edits in one place and keep the original Sass pristine for a future developer.
Teach them how to use a preprocessor.
I can hear you laughing from here. Stop for a minute and let me explain! I know this won’t work for every client. There are some for whom this method would be a disaster. You know who I mean: there are the “I know a little CSS” folks, and also the people who are so thinly spread doing a hundred things for their start-up or business or side project that they don’t have the bandwidth to learn Sass.
But if you have a client who can handle learning a new step, I would offer to train them to use the Sass partials you’ve set up. This will require an investment of your time and theirs. (If I were doing an “intro to Sass” training session with a client like this, I’d bet on at least a half day, probably a full day.)
Remember, you’re a professional and you should be paid for this time. If you can sell it to your client as an add-on toward the end, more power to you. On the other hand, if you think the client would do really well with this training but would not pay extra for it, add the cost of your training day into the site package cost & throw this in “for free” at the end.
Conclusion
Handing off Sass files to non-Sass site owners and maintainers sure isn’t the easiest thing to do. With some planning ahead, however, it can be successful. Please leave comments with other ways to manage this hand off or stories of how one of these methods has worked for you!
James SteinbachJames is a Senior Front-End Developer with almost 10 years total experience in freelance, contract, and agency work. He has spoken at conferences, including local WordPress meet-ups and the online WP Summit. James's favorite parts of web development include creating meaningful animations, presenting unique responsive design solutions, and pushing Sass’s limits to write powerful modular CSS. You can find out more about James at jamessteinbach.com.
