Write CSS like you're in the future with Stylus

Fri, 01 Feb 2013 00:00:00 -0800

Stylus has many great features. Its best feature it allowing you to write CSS as if you were in the future.

So what does the future hold? Mainly one thing.

No browser-specific prefixes

Have you ever written something like that?

.something {
  -moz-border-radius: 1em;
  -webkit-border-radius: 1em;
  border-radius: 1em;
  -moz-transition: all 1s ease;
  -o-transition: all 1s ease;
  -webkit-transition: all 1s ease;
  transition: all 1s ease;
  -moz-box-shadow: #123456 0 0 10px;
  -webkit-box-shadow: #123456 0 0 10px;
  box-shadow: #123456 0 0 10px;
}

You did if you wanted to support most browsers and display a box with a border radius and a drop shadow.

What's wrong with this picture? The spec doesn't mention browser prefixing. They're a solution to a non-issue. Yet, they are necessary for a few features of CSS3.

Coding in the future

Here's how nib fixes that with Stylus' seamless mixins (modified how nib actually does it for conciseness' sake):

border-radius(radius){
  -moz-border-radius: radius;
  -webkit-border-radius: radius;
  border-radius: radius;
}

transition(transition){
  -moz-transition: transition;
  -o-transition: transition;
  -webkit-transition: transition;
  transition: transition;
}

box-shadow(){
  -moz-box-shadow: arguments;
  -webkit-box-shadow: arguments;
  box-shadow: arguments;
}

Now in your .styl file:

@import "nib";

.something {
  border-radius: 1em;
  transition: all 1s ease;
  box-shadow: #123456 0 0 10px;
}

... will output the same CSS as above, all the while following CSS3 specifications.

Be a gatekeeper

Wed, 23 Jan 2013 00:00:00 -0800

In OSS, code is written by many people. Yet, it's advisable to collaboratively write code as if it had been written by a single person.

As a maintainer of OSS, you should be a ruthless gatekeeper. master is your fortress, in which you only let in worthy code.

What makes code worthy?

Code that solves a real issue.

Code that's useful for many cases and is built in an abstract, general fashion.

Code that follows the overall style of the project.

Code that's properly tested.

Pull requests are abundant, great pull requests are scarce.

Your duty is to read the entire code, question every line and every decisions. For the less-than-great pull requests: thoroughly comment in a friendly-yet-critical manner, pointing the developer in the right direction without revealing the answer. The goal being to preserve the consistency and quality of the code.