Introducing INIT – A Boilerplate Framework for Front-End Projects

INIT is based upon HTML5 Boilerplate and adds more structure for SCSS files, JavaScripts, includes build tasks and a whole lot more.

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.

Over at TNG I wrote a bit about why we need frameworks like these and what the challenges with current tools are:

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.

Please drop by and read the full article, provide feedback for INIT via GitHub or just tweet about it if you feel like it :)

INIT’s website    INIT on GitHub

Introducing CSS Modal

CSS Modals in action

In the last couple of months I’ve worked on several projects that needed an overlay with some content on it. Some front-end frameworks as for example Bootstrap refer to them as modals.
You can find a lot of implementations that do exactly what I search for but they all have one major drawback: They rely on JavaScript.

Yes, sure, everyone has JavaScript enabled these days but why use a technique that you don’t necessarily need for a given problem? Also most implementations have drawbacks when it comes to mobile devices and responsive web design in general or accessibility. Apart from that they add a lot of code, that is not necessary for a lot of pages. Others might add dependencies such as for example jQuery which you don’t need at all on your micro-site.

To tackle these problems I decided to write my own implementation of a modal that fulfills what I need.

Modals built out of pure CSS

CSS Modal is the result of this experiment.

Here is what is cool about it:

  • CSS Modal is built out of pure CSS while JavaScript is only for some sugar.
  • The modals are designed using responsive web design methods.
  • It is accessible, cross-browser, media-adaptive, small and fast!

Another cool thing is that you can use CSS Modal as Sass plugin and apply it to your custom classes using Sass placeholders.

Visit the website     View an example

Check out the website to get documentation and more examples. The project is on GitHub so if you use it and find bugs, please report them.

General feedback is also very welcome. Please tweet me!

The REM Fallback with Sass or LESS

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 relative to the root element of the page (this means the html element). Thus it is possible to define a font-size once on the root and make all other sizes depending on this size. Please switch over to Snook’s blogpost explaining what rem is to get more information about it.

If you ask yourself why you should use em instead of px, Chris Coyier wrote an article on why he switched to em instead of pixels a while ago for nearly all properties using units in CSS. Read this to understand why em and thus rem is so important.

I would encourage you to use rem (or at least em) for properties like padding, margin and sometimes even width instead of pixels. It makes your design even more responsive.

The drawback of rem is that it is not supported in all browsers that are used, even though the support looks pretty good: Internet Explorer is capable of dealing with rem since version 9. The versions before need a fallback. It is supported on the major mobile browsers except Opera Mini. Let us have a look on how we can define such a fallback using Sass or LESS.

A Sass Mixin

In order to get the pixel-based auto-calculation working as a fallback we need to define the font-size as a variable in Sass or LESS.
The following examples are in Sass with the SCSS-syntax.

$main-font-size: 16px;

We can now use this default font size on the root element:

html {
  font-size: $main-font-size;

Now we define a mixin that provides a fallback pixel-based size of the property based on the variable we defined before and in rem for capable browsers.

@mixin x-rem ($property, $value) {
  #{$property}: $value * $main-font-size;
  #{$property}: #{$value}rem;
}

What the mixin does is, that it takes the $property and calculates the value in pixels. This simple mathematic function is part of Sass. The $value argument is a decimal digit.

I like to prefix my own mixins with x- to easily distinguish them from other mixins. This is a part of the Idiomatic CSS principles by Nicolas too. I think previously I prefixed them with a namespace (mostly it was the- as a prefix, so you get the-transition) – but since there is a better convention with Idiomatic CSS I switched to it.

This mixin can be called like in the following examples:

@include x-rem(font-size, 1.4);
@include x-rem(padding-left, 2);

The output that is being produced looks like this for the first example:

font-size: 22.4px;
font-size: 1.4rem;

You can use Sass’ round() function to get an integer output for the px-based output. But every browser is capable to round 22.4px by itself to 22px since it is not possible to display 0.4px after all. (LESS has the same function.)

A Few Words On The LESS Mixin

In LESS interpolation for properties is current not possible with version 1.3.x. The maintainers aim to include it in version 1.4. For the time being we need to define a workaround for properties which is basically a JavaScript function which returns a sting that consists of two properties instead of one, while the first one is - which is basically no property an thus disregarded by the browser. The second is the property that we want to use.

Here is the first line of the mixin:

-: ~`(function () { return ';@{property}: @{px-fallback}'; }())`;

This only works if the LESS compiler uses the actual JS library. It does not work with lessphp or other compilers that are not JavaScript based.

Final Words

And that is it. The mixin provides a decent fallback for rem-based sizes of all kind. Since CSS runs stable with this version of a fallback and overwrites the pixel-based value because of CSS’ cascade we can use it without any problems. It works in old Internet Explorers.

Life is easy with rem. So look at the Gist and use the rem-fallback-mixins.

Sass and LESS mixins

Credit

I want to mention that I first saw this technique used by Divya Manian a year ago (beginning of 2012) when working on the HTML5 Please API project. I am not sure who developed this technique or where it comes from. Please let me know if you have a link.

Addition: The Susy framework has a Sass mixin which lets you easily convert units including the rem unit and a fallback as described here. (Head-tip Fabian Beiner.)

Addition 2: Steffen wrote a Sass mixin which lets you use the short notation of properties like margin or padding. Even mixing values as px and rem is working. Cheers!

Yeoman – Level-up Your Daily Workflow

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 and what will be helpful. If you haven’t had a look at it this article might help you.
Continue reading “Yeoman – Level-up Your Daily Workflow”

An Approach on Building an Advanced Initial Boilerplate

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.

Visit project on GitHub       Download

Not just HTML5 Boilerplate …

With HTML5 Boilerplate we are creating an awesome starting point for front-end developers that want to use a solid boilerplate that has defaults that are useful for everyone. Besides that we want to keep it simple and straightforward. That’s why adding a preprocessor or complex dependencies to HTML5 Boilerplate is not possible.

For the team I’m working with at /gebrüderheitz and me it’s important to have a solid basis for projects we do that we can use over and over again. Other developers have this need too and that’s why there is Twitter Bootstrap or ZURB’s Foundation (just to name two) out there.
Just while developing this project my buddy Kahlil came up with a nearly similar approach: HTML5 Boilerplate on Crack. He has different things in his package then init has. Keep an eye on that.

Simplify Development

For init I decided to use Grunt.js as a development- and deployment-tool. Grunt is a Node.js based task-oriented tool that simplifies developing and deploying JavaScript a lot. Since Grunt has a big and valuable community there are a lot of plugins that you can use with it to help developing HTML and CSS too.
Currently we are thinking about including Grunt into HTML5 Boilerplate, which is a great step in moving the project to the next stage.

As stated before I love using SASS as a preprocessor and I have some structure I like to apply to my SCSS-development files which I already outlined in my post about my personal coding guidelines. This requires to have Ruby installed on your local machine to compile SCSS into a CSS-file or to use a tool like CodeKit that does everything for you. I am actually a big fan of CodeKit but also like to have the compilation as part of my whole build process for a website.

SCSS compilation is integrated in init’s Gruntfile.
By running grunt watch you start a process which watches for changes in your SCSS-files and compiles the CSS-file automatically unsing Sindre Sorhus’ awesome Grunt-plugin grunt-sass. Besides that the watch-task recognizes changes in your JavaScript files and lints them on the fly.

If you’re not dependent on any special server-environment you can easily fire up ./server.sh on your console to start a small Ruby-server with a tab in your favorite browser.

There are a lot of other goodies in the project. Please visit GitHub and read the project’s readme-file for more information.

I’d also encourage everyone to keep an eye on Yeoman since I think it can do a lot more then my package does and will be awesome. It will be available soon.

It’s Open Source

This project is Open Source and I would love to see some people chiming in and discussing the project in its current state to make it better. I’d love to get some feedback from all of you!

Apart from that please feel free to use it for your projects. It’s all under MIT License and thus pretty much there for all your needs.

Thanks for being awesome, community <3!!

SASS vs. LESS

“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.

RECESS – A CSS cleaning tool build on top of LESS

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!