This week I published another one of my small projects, a Sass micro-library by the name of sass-named-colors. The purpose of this is simple: provide an easy interface to a standardized list of 1,500+ named colours originally compiled by Chirag Mehta and converted to Sass by James Pearson. No need to puzzle out hex values; just use k-colour(emerald), k-colour(monsoon), k-colour(cloud), and so on. The library also features aliased functions and variable names for those who prefer to work with colours (the non-American spelling), admittedly a bit of a pedantic flourish. Plain old “colors” is the default, though personally I stick with the spelling I am used to in my own work (and in this post).
Installation is a breeze via Bower: bower install sass-named-colors -D. This library has no dependencies but requires Sass 3.3+ due to reliance on the map-get() function and an approach outlined by Erskine Design.
This library ships with one function: k-colour($colour, $fallback, $library). Only $colour is required; the remaining arguments are mainly for internal use. Example:
Sass Font Stacker is a small library of web-safe font stacks bundled with some utility functions and a simple mixin to make font-family declarations a breeze. The syntax is similar to what you’d be writing anyway. For example:
The mixin (and related utility function k-font-stack() accepts an arbitrary list of fonts but requires the last (or only) argument to match one of the pre-defined font stacks. This way you can specify naming variations or even entirely different fonts at the head of a custom font stack.
I won’t list all the font stacks included in this project (as this information is likely to change) but will cite a few of the more commonly used fonts in web design:
Helvetica Neue Light
Times New Roman
All of these stacks contain a liberal sprinkling of Croscore, DejaVu, Liberation, and URW++ fonts for those viewers who lack the proprietary fonts common on the big two operating systems.
Crafting web-safe font stacks is more an art than a science these days. Usage data is neither current nor of a sufficient quality to make anything better than an educated guess in my estimation. But hey, a good guess is better than nothing—and the use of a Sass library allows for those good guesses to be formalized and consistent across projects. If anyone out there has expect knowledge to contribute please consider opening an issue or sending a pull request. Here’s that GitHub link again: Sass Font Stacker.
Update February 2015: this post is now out of date as the starter kit has evolved. I’m working on a new post to explain all the developments; in the meantime please check out the original repo on GitHub. Thanks!
Since then I have refined my workflow to the point where I figure it might be helpful for me to share my approach with the WordPress community. With this in mind I have prepared this starter kit (with source code on GitHub) to demonstrate how you can use Gulp with Bower and Sass to optimize your WordPress theme development workflow. This starter kit does not contain any actual WordPress theme files—it is meant to act as the scaffolding that surrounds your theme and supports your workflow.
These days I have been doing a fair amount of work with Sass, a CSS preprocessor. I have some experience with Compass but haven’t used it for my last few projects. It just feels like overkill—particularly when I am only using a handful of its functions.
Bourbon recently jumped out as a lightweight alternative to Compass. But then it hit me: both of these frameworks concentrate on solving a problem I no longer have: vendor prefixing.
Synaptic/dev is a technical blog focusing on web design and development. GitHub is home to all my open source software projects; open an issue over there if you're having any trouble or find me on Twitter for quick inquiries.
Drop down to the root of this domain and visit Synapticism to have a look at my more personal blog.