Category Archives: General

Easy-peasy Rem Conversion with Sass

I love rem. I’ve been using it since I first read about it in Jonathan Snook’s article, and even more so since I started building responsive websites.

So what is rem?

Rem is a value that is relative to the root font-size, meaning the font-size that is set on the <html> element. The browser by default sets the font-size at the root to 16px.

There are some articles around about why rem is good and super handy, so I won’t go into too much detail here. But in short, rem is awesome because:

  • It works like pixels in that you don’t get compounding issue like you do with em and the computed value is always the same no matter where the value is set.
  • It is better accessibility wise as it can be scaled like em, so users can resize the text on the page.
  • In responsive design, you can set a different font-size on the <html> at each breakpoint and the text on your site will scale proportionally according to your root font-size.

The only “issue” with rem is that it’s not supported by older browsers, namely IE8 and lower. So to use it, you’ll need to include the font-size in px as a fallback. But in my eyes, its benefits outweigh this small “issue” by far.

Using rem in our projects

Since we started using Sass for our projects, to make things more convenient, we wrote a mixin that will convert the input px to rem. It also outputs the px value as fallback for browsers that don’t support rem.

Creating the function

So first step, we need to write a Sass function that gets the rem value based on the px value that has been passed in. To do this, we need to divide the input px value with the default 16px set by the browser:

@function calculateRem($size) {
  $remSize: $size / 16px;
  @return #{$remSize}rem;
}

You might ask, “What if the user has a different default font size in their browsers”? Well, the great thing about rem is that the text will just scale proportionally like em! Pretty good, right?

Creating the mixin

Next we create a mixin that calls the function:

@mixin fontSize($size) {
  font-size: $size; //Fallback in px
  font-size: calculateRem($size);
}

Now your mixin is ready to be used! To use it, simply include the mixin wherever you need to declare a font-size.

Sass:

h1 {
  @include fontSize(32px);
}

Output:

h1 {
  font-size: 32px;
  font-size: 2rem;
}

With simple Sass functions and mixins like this, we save a ton of time and human errors from punching numbers into our calculators.

You can find all the code to convert rems from pixels on the OOCSS open source project.

Creating Living Style Guides to Improve Performance

I recently spoke at JSConf about my experience working with Trulia to create a living style guide. The goal for the project was to improve performance, team velocity, and also to have a more consistent design. It was such a fun project (because their engineers were great to work with) and also successful on all three fronts. Here are some of the metrics for the data-lovers:

  • Their HTML is 48% smaller
  • 21% faster load time
  • 60% faster time to first byte
  • Reduced unused CSS by 135kb
  • Search results page views increased by 11%
  • Property detail page views increased by 3% (this page was not changed, changes on the SRP alone account for this figure)
  • Click throughs, leads, customer satisfaction, and filter use also improved

I’ll be speaking at Velocity Conference in a couple weeks where I’ll go into more detail about the Sass magic that made this possible. :)

Why I run my business like an open source project

When I first started consulting, I used to squirrel away in my corner and code. Some weeks later, I’d deliver my perfect shining gem to the client after, quite frankly, trying to talk to them as little as possible throughout most of the process. It wasn’t that I didn’t like people, I especially enjoyed talking with developers, but the gap between what I knew I needed to do to get the job right and my ability to explain it to the client seemed insurmountable. With repetition, my ability to explain technical requirements in a management friendly way has evolved to something like passable, but an equally important change has been Github.

Github

Github has allowed us to take a different path with our projects. We now treat them much like open source projects. We strive for transparency and clarity in everything we deliver as well as in the process by which we deliver it. We often do complex UI rewrites and performance evaluations for big companies like Facebook, Paypal, Adobe, Salesforce, Trulia, Williams Sonoma, Pottery Barn, etc. Big companies have a lot of stakeholders and we’ve found that Github is an amazing way to include them in the project from the beginning.

Our clients have access to the code we are writing from the first line we commit. When my developers and I code review each other’s work, the client can see and also participate in that code review. In that way, they get to understand (and buy in on) not only the end result, but the rationelle behind it. Clients also send their developers to work side by side with us. We take them in as a part of our team, submit them to the same grueling code reviews we all go through.

We’ve found that they are happier this way. The transparency I feared, the risk taken by trying to explain something and failing, has been far outweighed by the practical benefits of healthy collaboration. They now feel the end result belongs to them, rather than being something forced on them from outside or upper management.

Glorious bugs…

There is also something great about letting a client peek inside the works… they find bugs, omissions, and misunderstandings. Why is that great? Because they find them right away, rather than several weeks or months into a project. They also feel empowered to open github issues for those bugs, helping us do our job even better. Instead of it being a terrible thing to find bugs, it becomes an ordinary part of the process. I usually explain it like popcorn popping. For a while you will have a lot of pops, and then slowly it will wane and you’ll just get a pop every now and then. When the pops become pretty infrequent, we move the code from our repo to theirs. I hope this means our clients trust us, because they get to see that we will continue to show up for them throughout the project and that we’ll always have a curious, relaxed, and grateful attitude when they identify something that needs fixing.

We didn’t want you to work on that!

It also means that there isn’t any issue of “we didn’t ask you to work on that”. The client gets to approve all work (in the Github issue for the feature) before we even get started. They also get to see the kind of bugs I assign to Fiona, or she assigns to Arnaud and get a sense of the teams strengths and weaknesses. That helps them know who to contact when an issue comes up. Yay for anything that makes me less of a bottleneck. :)

And the most important reason? Code quality

I’m a firm believer that open source code is of higher quality than code written in a vacuum. I can’t say if that is true for every project out there, but it has certainly been true for us. Greater transparency has enabled us to have a tighter feedback loop and make a few things I’m quite proud of.

Anyway, I could go on and on about this because I’m quite passionate about how an open source approach and Github in particular has enabled us to improve our work, but I’d love to hear from you. Have you used github in this way? Do you use it internally? What works? Any tricks? I know their are a few features I still wish existed, how about you?

CSSConf – The selection process

CSSConf – This is your conference.

Last week we invited the CSS community to submit talks for the upcoming CSSConf (May 28th, Amelia Island, FL).

The CSS community has an excellent history of curated conferences, and yet we want to do something a little bit different. We want to see what you have to say! What do you think is cool? What are you working on that you would like to share with the community? We decided to do a Call For Proposals because we wanted to balance curation with community.

Some folks may not be familiar with a CFP. It comes from the scientific community, when scientists would submit a proposal to present their work to their peers. The scientists with the most interesting abstracts would then be chosen to display a poster describing their work at a conference.

We decided to build on this model because we firmly believe that the community is doing amazing things. We are excited to hear about them, and to help you share your work with others.

Choosing the best talks

We are following the JSConf EU method so that we can choose the absolute very best proposals that come in.

The most important part is that we have eliminated all identifying details when we are evaluating the quality of your proposals. We won’t see your name, your company, or whether you have spoken before or are brand new to speaking. This means you have a chance to speak if you are famous but also if you have never set foot on a stage. Each of the proposals will be evaluated on it’s own merit. We’re excited about this process, and we hope you are too.

(After the first two rounds of selection are complete, we will reveal your names/locations so that we can do important things like figure out if travel from your location will fit in our budget).

Submit your proposal

If you want to know a little more about how we’re doing it, or, even better, you want to submit a proposal, head on over to the CSSConf Call for Presentations. Thanks for being a part of this. If you have any questions, or need any help getting your proposal together, don’t hesitate to get in touch with us at contact@cssconf.com.

by Sam Gao

Don’t Feed the Trolls!

I gave my first-ever keynote this week at Fluent Conference. It was fun and terrifying, in particular because I spoke about a non-technical topic, trolling in the web community. Here is the video:

UPDATE: If you would like to take the test I mentioned to uncover your own biases, it is a research project called Project Implicit from Harvard University. Please forgive the 1999 styling of the site. :)

And, Don’t feed the trolls slides.

Photo Credit: Sam Gao