Browsing posts in: Development

Repeating CSS – Trying to Stay DRY

Some sobering numbers from a recent article on titled “70% Repetition in Style Sheets: Data on How We Fail at CSS Optimization” by Jens Oliver Meiert, shows the web as a whole has a CSS problem. For example Engadget has 28,909 CSS declarations with only 2,382 of them being unique. Other sites like Kickstarter and have similar stats.

What this shows me more than anything is large sites with large legacy code bases tend to have under-optimized bloated stylesheets. It’s no surprise to any of us that have been in the industry for a while especially if we have ever worked for a large organization. The fact is CSS optimization is hard. I agree with the author though in that we have to try. That is probably why I am a fan of the ongoing conversations about CSS through Javascript. While I might not agree all the time with those conversations, I do think having them is important to moving beyond the issues we see with large CSS codebases.

Favorite email development tools

Developing emails can be as simple as writing some HTML and sending it through an email application, but it’s a bit more nuanced than that when doing complex emails. Here are some tools that help keep me consistent:

Litmus or Email on Acid – both have pros/cons but having at least one is essential for testing

Parallels or VMware – I develop on a Mac, so seeing it opened in Windows is really handy for testing emails. Litmus or Email on Acid are great, but having an actual “native” device is great for confirming the render.

Office 365 – Always having the latest Outlook is super important when testing. Of course I keep older versions too, but Office 365 has bailed me out on a number of occassions.

Grunt or Gulp – Build tools are the standard for web development, but tools like Grunt and Gulp are really helpful in email development too for inlining CSS, zipping up folders for uploading to testing platforms, validating HTML, optimizing images, and even sending test emails.

Putsmail – For quick email tests, nothing seems to beat Putsmail (now owned by Litmus). Just paste in your code and send. Just make sure your images are hosted somewhere other than your computer or they won’t show up.

Campaign Monitor – I used to use MailChimp as my testing tool, but Campaign Monitor offers unlimited test sends which is critical for fully flushing out any bugs. I’ve also found that Campaign Monitor’s UI better suits my workflow when developing emails. I wish it had an API I can call directly from my build tools, but that’s getting super geeky.

Why I prefer email development

It’s no secret web developers and designers generally don’t like working on emails. Heck most of us don’t even like receiving or processing email, and often the emails that are “designed” are the ones we send immediately to spam or trash. However there are some reasons why email development can actually be rewarding and easier to deal with.

Here’s why I’ve transitioned almost all of my freelance work to email development:


What??!! I know you think I’m crazy, especially if you’ve ever tried to troubleshoot and test emails on different applications or devices. But considering the ever-changing web standards, frameworks, hardware capabilities and devices, developing for the web has become a bit overwhelming to keep up. Email on the other hand moves at a much slower pace. I know next year, the process for developing an email will be pretty similar as today. That lack of change can be limiting, but also frees me of having to code to the latest advances.

Simpler builds

Pre-processors, post-processors, server configurations, deployment, content management systems, Javascript frameworks, CSS frameworks, minification, concatenation, CDNs, back-end, front-end, APIs, and you name it. Creating a website has become a complicated process. Email development remains mostly static although it can be “simplified” with web build tools like grunt and Sass. That means I can sit down in front of a text editor, bang out HTML and inline CSS, and send it immediately. I love that simplicity!

Short-term projects

I have a full-time gig and a family. I like freelance, but I also like my free-time. Emails rarely take longer than eight hours to develop and often only consume a few hours of my time. Meanwhile websites can take months to finish depending on how much time I can dedicate. I guess it depends on your personality, but I’ve always been a sprinter and not a marathoner.

Instant results

Once an email is deployed through a platform like MailChimp or Campaign Monitor, I can instantly see open and click through rates as well as a bunch of other useful information. These analytics can help determine conversion rates, best times to send, and deliverability of emails. There’s also something satisfying about knowing my email I just developed was “hand-delivered” to thousands of customers at once. This argument can be made about web to I suppose, but I like seeing the mail-list numbers when I hit send. Weird? Maybe.

Fine-tuning my skills

Developing for email is challenging and can be incredibly frustrating. Because the time frame for each email is significantly shorter than websites, I can bust out dozens of emails during the same time period it would take to development a website. This repetition allows me to fine-tune my skills much quicker than I could with developing websites. Ultimately this makes me much happier and more confident as a developer.

Making more useful

No front-end developer today can get by without knowing browser support for all the latest HTML and CSS features. Luckily Alexis Deveria’s provides the ultimate visual cheatsheet for this. Using the website is great; however, lately I’ve longed for something more. Two tools—When Can I Use Web Widget and caniuse-cmd—is exactly what I was looking for:

1. When Can I Use Web Widget by Andi Smith gives me the ability to add information on blog posts

The “When Can I Use” Web Widget provides authors with the ability to include up to date information about browser support for a feature they are talking about based on the data crafted by

2. caniuse-cmd by Sam Gentle allows me to use caniuse in command line! Seriously can’t applaud this enough

$ caniuse websockets
Web Sockets ✔ 85.22% ◒ 1.35% [W3C Candidate Recommendation]
Bidirectional communication technology for web apps #JSAPI

IE ✘ 5.5+ ✔ 10+
Firefox ✘ 2+ ◒ 4+¹ ◒ 6+ᵖ² ✔ 11+
Chrome ◒ 4+¹ ◒ 15+² ✔ 16+
Safari ✘ 3.1+ ◒ 5+¹ ◒ 6+² ✔ 7+
Opera ✘ 9+ ◒ 11+¹ ✔ 12.1+

¹Partial support refers to the websockets implementation using an older version of the protocol and/or the
implementation being disabled by default (due to security issues with the older protocol).
²Partial support refers to lacking support for binary data.

Tips for CSS calc() usage and syntax

Honestly I don’t know what I ever did before calc() especially for calculating margins. Here’s some helpful tips and tricks I’ve read about and used in the past:

1. Ana Tudor, writing for Smashing Magazine:

We need to keep a few things in mind to ensure that the calc() function works. First, division by zero obviously won’t work. Having a space between the function name and the parenthesis is not allowed. And the plus and minus operators must be surrounded by white space. This means that the following are not valid:

calc(50% / 0)
calc (1em + 7px)

I highly recommend reading Ana’s full article if you are just getting started with calc() or you simply need a refresher.

2. Vincent Pickering writes:

A quite common design decision is to have multiple containers within a wrapping container. The inner containers will be a percentage width of the outer container, so are equally spaced. Given this scenario, you would usually just assign width:33%; to each container and move along. But sometimes, you want extra flexibility for those containers. For example, if you want each box to have a border, you then have to take this in to account as well.

Calc to the rescue again!

width: calc(100% / number of boxes – total margin size);

3. If you’re using calc() in Sass, don’t forget to interpolate the variable!

$var: 10px;
height: calc(100% - #{$var});