Today we released INIT, a front-end framework based on Grunt, Bower, Karma and a lot more tools as version 1.0. This marks a special day for Anselm and me, as we worked for a long period to get this project to where it is today.
Generally we start a lot of our projects in kind of the same way. A lot of tasks need to be repeated from one project to another since we tend to set up our development and deployment workflow in similar ways everytime.
Since a while now word has spread to use the CSS unit rem for font-sizes and values in CSS. Here I want to explain how you can use a fallback in Sass or LESS to get rem working in all browsers. View Gist with mixins Why rem? Let’s look into what rem means. We know of the em unit which is relative to the font-size of the parent element it is defined on. This means if one of the parents in the DOM-tree changes its font-size, the font-size of the child element changes too. In contrast the rem unit is
After Yeoman was announced in the end of June while it was still in private beta developers were looking forward to use it soon. It was introduced as a tool that helps developers building web-apps while not having to care too much about the general boilerplate-coding to build a solid base for every project and to help performing tasks to bring your project into production. Now that Yeoman is available for everyone as Open Source the question how to use it in daily projects arises. I’ll try to give you a short overview on what you can expect from it
Since some time I found myself defining a good starting point for a new project over and over again. While I use HTML5 Boilerplate in nearly all of my projects it’s not enough as an initial package. Since I’m using SASS (in its dialect SCSS) and have some other things I define over and over again I decided to set up a package that lets me start easily and includes a lot of tools that are necessary for my projects. This is an introduction to init, the starting point for projects that require a bit more than just HTML5 Boilerplate.
“Which CSS preprocessor language should I choose?” is a hot topic lately. I’ve been asked in person several times and an online debate has been popping up every few days it seems. It’s nice that the conversation has largely turned from whether or not preprocessing is a good idea to which one language is best. Let’s do this thing.
Really short answer: SASS
Slightly longer answer: SASS is better on a whole bunch of different fronts, but if you are already happy in LESS, that’s cool, at least you are doing yourself a favor by preprocessing.
Chris Coyier finds an answer to what preprocessor is the better one by pointing out what the advantages of each preprocessor are. And as it turns out SASS is winning the race because it has more power and better features. So if you are asked why you use SASS, you might want to link people to this post.
Developed at Twitter to support our internal styleguide, RECESS is a simple, attractive code quality tool for CSS built on top of LESS.
Incorporate it into your development process as a linter, or integrate it directly into your build system as a compiler, RECESS will keep your source looking clean and super managable.
As I think reading the source is essential for developers to become good at what they do viewing this source in readable style is essential too. RECESS is a tool which helps you developing good-looking CSS with LESS. It is developed at Twitter and has now been open-sourced.
RECESS is a Node.js module and is maintained by @fat. You can find out more about it by viewing the source at GitHub.
BTW: I’ve decided to not minimize and concatenate my blog’s source anymore. So, feel free to dig deep!