Article Archives

Dropdown Default Styling

There has always been big differences across how different browsers handle form styling. There probably always will be - because UI design choices aren't described in the specs. Browser makers perhaps view this as one of the ways they can differentiate the user experience a bit. Select (dropdown) menus are one that is particularly weird.



The next generation of Zen Coding. Essentially it gives you shortcuts you can type that expand into full HTML or CSS. Like nav>a*8 will expand into a <nav> tag with eight links inside it with empty hrefs. Or, try div.module*4>p*2>lorem and press tab. There are also a bunch of editor navigation shortcuts like "move to the next edit point."

Display Form <progress>

Imagine you have a form with 10 required fields on it. That's a bit larger than your average form on the internet and a good bit of work for a user. You might lose some users along the way, which is never a good thing. Perhaps to encourage finishing the form, you let them know how close to completion they are, and display motivational messages along the way.


Web Developer Economics: Hardware Costs

This will be the last part of this mini series about Web Developer Economics before we wrap it up and look at the numbers together. We already looked at:

Now we need to consider the hardware itself. I think this one is pretty simple: you need a computer.

I think you need either a laptop or a desktop. Maybe someday in the future the tools will be there to build websites on tablets or other futuristic devices, but I don't think we're there yet. Laptops these days are so powerful that it's hard to imagine going any other way. You can plug in an external monitor to get a desktop experience, or take them with you. Unless you're like a school computer lab or office where nobody works from home ever, it's hard to imagine going with anything other than a laptop.

I know this site is pretty Mac-focused. That's what I like and use. But I promise you: I really don't care what you use. I'm way more concerned that you are writing maintainable CSS that I am about what kind of computer you are using. If you're happy on your PC running Ubutunu (or whatever) and you're making good websites, you're A-OK in my book.

That said, if you're buying a computer right now to be a part of your web design/development life/business and you ask me what I think you should buy, you should buy a ...

MacBook Pro (Retina, 15", $2,199)

As I've written, this is the best computer I've ever owned. It's worked extremely well for me. I feel very productive on it. It runs all the best software for web development (that I know of). This retina display screen looks great, but as a developer allows us to be ahead of the curve in designing for devices of this pixel density (technically you could write code and build graphics to support it without owning one, but you need to have one to care).

Alternatives: Any other laptop or desktop computer that works for you.

Microsoft Natural Ergonomic Keyboard 4000 ($49.95)

I use this and like it when I'm at home and at my desk. I have RSI (repetitive strain injury) problems when I'm away from it (using laptop keyboard only) for too long.

Alternatives: Use built-in laptop keyboard / some other external keyboard

Kensington Expert Mouse Trackball ($99)

Also helps my RSI but also I think is just a very efficient mouse in that you never need to pick it up or do awkward motions with it. I miss the trackpad when I'm in desktop mode though, with its gestures and wicked fast scrolling.

Alternatives: Use built-in trackpad / some other external mouse

Brother HL-2280DW ($199)

This is a very nice and efficient printer. Wireless, laser printer (cheap ink), and does stuff like automatically print both sides of documents to conserve paper.

Alternatives: Go totally paperless / some other printer

None of these accessories are vital to my job but I consider them business expenses. I bet most of us have a few accessories like this. They might not be these, but you have some, so we'll include these in the final calculations to keep it even.

Office space might be considered a "hardware" expense of sorts. I'm not going to consider that here because it's optional. I don't have an office. If you work somewhere that does, that's factored into the cost of running a business there either by you or the owners of that business.

Service Cost
MacBook Pro $2,199
External Keyboard $49.99
External Mouse $99.99
Printer $199.99
Total $2,548.97

With these numbers and the ones gathered from other posts, I think a wrapup is in order looking at them all together and see what we see. Look for that soon.

ShopTalk Episode 40

Dave and I talk with Laura Kalbag, a freelance designer from the UK with a fresh perspective on just about everything. We talk about process, selling responsive web design, software choices, and more.

Thanks very much to PeepCode and InControl for sponsoring this week.

CSS-Tricks Chronicle VII

I don't think I mentioned this here yet, so: I redesigned my personal site. It's nothing mindblowing, it's just some simple boxes with words in them. I'm happy to have shed my old site which was full of old junk. I'd be happy to have you read it, but the posts will be personal and rarely about web stuff or tech. I will be bringing comments back on it as soon as I can.

The most interesting fact about it: Other than one declaration of font-family, I used no typographic CSS at all. The user-agent stylesheet in browsers has a reasonable set of defaults for text elements and I just went with it.

I started using Divvy and it's been super helpful. It's just a tiny little menu bar app for Mac that allows you to position windows based on a grid you set up. I'm pretty messy with my open windows, and I'm often fiddling with them to get a useful arrangement. Usually, that's browser-on-the-left and sublime-on-the-right. Divvy allows me to get into that setup in just a few commands. It's the little things, right?

As I've written about, I absolutely love the idea of working in public. It's super cool that Daniel Mall and team will be doing it with the Reading is Fundamental website.

I was on the SassCast with Dale Sande recently.

Speaking of Sass, as I'm rewatching and writing notes for the last of the videos in The Lodge, it occurs to much how much Sass is in all those videos. If you're looking to dig into learning Sass and what it's like on real world projects, you could do worse than watching the videos there.

Speaking of The Lodge, I recently spoke with a member who lived in New Zealand. Apparently the internet is quite slow there, and it would take an incredibly long time to download all the videos. I agreed to send them little USB drives with the videos on them. If anyone else is in that position, let me know and I can do the same for you. I need to charge $150 for it though, as the drives of that size are a bit expensive and requires me doing some work.

I made this kinda neat "stairway" style navigation. It's probably a little obnoxious for general use but it could work in some contexts. I used to blog stuff like this after I built it, tutorial style. I should get back to that.

As I type I'm right in the middle of a big multi-leg trip. I was in New York for the first time for FOWD which went very well. I got to be the keynote on the first day! I loved Zoe Gillenwater's talk about future layout specs. Carl did a great job keynoting the second day. I sadly missed Darcy Clarke's talk but he does have some videos of us hanging out that should never make it to the internet.

I got to visit Vimeo's office while I was there thanks to Joe.

My travels this year are far from over. Next I'm headed to Baton Rouge to visit Richard, who I've been nerdfriends with since long before CSS-Tricks was even a thing.

Then I head to Salt Lake City for a day to give a workshop for Deseret Digital, who backed me on Kickstarter to the level of a personal workshop. Then back home for a few days before flying to Philly to do another one of those. Then Hawaii for the conferences there, then back to Wisconsin again for the holidays.

It has been and will be a lot of fun, but I'm sensing the travel burnout coming and I've purposely been very protective of 2013 - keeping it as absolutely free from commitment as possible. I'm at my best during long periods of simple home living.


You know those online slideshows where the text for new slides three dimensionally rotates in? Those are made with Reveal.js by Hakim El Hattab. Now there is a web app for creating them so it's even easier.

Updated :nth Tester

Just a quick post to note that I've updated the :nth Tester page to hopefully be a bit more useful than it was before. The purpose of the page is to learn in an interactive way how the selectors :nth-child, :nth-of-type, :nth-last-child, and :nth-last-of-type work.


David Walsh on Redesigning with Sass

The following post is by David Walsh. David is a web developer from my own hometown of Madison, Wisconsin and currently working for Mozilla.

David recently redesigned his blog and is having a series of guests write posts for his site. We decided to do it crossover style: he writes an article for CSS-Tricks and I'll write an article for the David Walsh blog. He used Sass in his redesign and his article below is about that experience. I've been using it for closer to a year, so my post on his site is about that experience.

Creating any website without using a CSS preprocessor seems a horrible decision.  Even if only to be able to quickly modify a few colors or element dimensions, or even just to easily merge and compress CSS files, CSS preprocessors are becoming essential.  For my recent redesign of the David Walsh Blog, I decided now was the time to dive face first into CSS preprocessors.  Here are a few thoughts about my experience, and hopefully you pick up a few tips along the way.

Deciding to be Sassy

There's not much a decision to be made about whether or not to use a tool like Sass or LESS, the questions is more of which should be used. In the end, I chose Sass because:

  • my experiences with LESS have been ... less than appealing; the tool seems ... less maintained
  • a utility like Compass, a collection of mixins with an updater, is invaluable
  • the extend() API looked great
  • embedding media query styles within a selector improves organization
  • sprite generation is a huge time-saver
  • Chris Coyier told me to!

When you author a blog like David Walsh Blog or CSS-Tricks, learning a new CSS utility also presents the perfect opportunity to write about another useful topic.  Using Sass on this project was obviously the best choice.

Useful Snippets

Here are a few of the Sass snippets I used often on my site:

Vendor Prefixing

@mixin vendorize($property, $value) {
	-webkit-#{$property}: $value;
	-moz-#{$property}: $value;
	-ms-#{$property}: $value;
	-o-#{$property}: $value;
	#{$property}: $value;

Float Clearing

@mixin clear() {
    &:before, &:after {
        content: "\0020";
        display: block;
        height: 0;
        overflow: hidden;
    &:after {
        clear: both;

Offscreen Text

@mixin linkTextOffscreen() {
    text-indent: -9999px;
    overflow: hidden;
    text-decoration: none;
    display: block;
    font-size: 0;
    text-align: start;

:hover, :active, :focus Styles

@mixin hoverActiveFocus($property, $value) {
    &:hover, &:active, &:focus {
        #{$property}: $value;

I used these mixins quite a bit throughout my code. A few of my snippets mimic functionality provided by Compass, but I like seeing the specific styles provided by mixins.

Mistakes, Mistakes

As with using any tool for the first time, I made quite a few mistakes.  Mistakes are healthy though - you learn from them and write about them so others don't take those same missteps.  Mistakes I made include:

  • Nesting == Bloat:  The biggest mistake I made with Sass, by far, was nesting styles when they didn't need to be.  At the time of launch, my main CSS file was a vomit-inducing 59k!  I'm still working toward reducing the size of my styles, and it's a much more difficult task now that the site has launched because of...
  • ...Specificity Clashes:  Because of my issue with nesting styles when I didn't need to, I ran into a bunch of specificity clashes, bloating my CSS file even further.  When it got to the screen size media query CSS, I was needing to mark everything as !important.  That's an incredible amount of CSS bloat and hassle because of improperly using SASS selector nesting.
  • Sprite Generation... Too Late:  One of the big reasons I chose SASS was because I knew SASS managed sprite generation.  What a time-saver, right?  Well, only as long as you knew how to format them in the first place.  My problem was that I created my CSS with normal background-image declarations, without paying attention to SASS' desired format.  I went to create my sprites after knowing the correct format and said "WTF FML".  In the end, I created my own sprites because I didn't write my SASS correctly in the first place.  Very annoying mistake.
  • Duplicating Compass-provided Helpers:  I don't need to cite them... I'm more than certain I duplicated functionality provided by Compass.  I'll likely pay for it later if I don't update my code and stay aware of browser capabilities.

Tips and Last Impressions

I want to leave everyone with a few tips for getting started with SASS, and share a few last impressions of Sass development:

  • Despite my duplication of Sass-provided functionality and nesting issues, Sass is an incredible tool that, accompanied by Compass, provides the ultimate tool+updating environment available.
  • When nesting selectors, ask yourself if it's really necessary to do so.  Sure nesting also allows for better code organization, but a bloated stylesheet makes all of your users suffer.
  • Create variables for your CSS animation properties, especially duration and delay. Consistent animation timing ensures eye-pleasing UI effects.
  • Create variables for block padding, and use simple equations ($blockPadding/2) for lessor blocks. This ensures consistent element spacing.
  • You can nest media queries for selectors but I prefer creating a separate file for mobile / media query-specific styles;  it allows me to see the entire set of mobile styles in one glance. The same could be said for my print styles.
  • I used these directions to add Sass syntax highlighting to Sublime Text 2.
  • Keep track of your CSS file size(s) while you code, and periodically review your nesting strategy to avoid style bloat.
  • Utilize CSS animations as best you can -- they can save you a load of JavaScript code down the road.

In the end, I'm incredibly happy with my decision to use Sass as my CSS preprocessor.  The documentation is helpful, you can get up and running in a few minutes, and Compass is an invaluable tool in so many ways.  My only problems with SASS were self-inflicted, and will be easily avoidable the next time around.  Give Sass a chance for your next website or redesign - its usefulness is immeasurable and will pay off for the duration of your project.

Smashing Mag CSS Q&A 4

The fourth installment of my Q&A series on Smashing Magazine features questions about SVG fallbacks, vertical rhythm, retina media queries, and several more.


Eventually, we'll all be writing code in the browser. It just makes too much sense. What will get us there is projects like this which make the experience better instead of the same.

Aims to be the canonical non-vendor-specific documentation of web features. The major browser vendors are on board. It's in "alpha" so things are a little rough.

A noble goal, to be sure, but it feels strange to me. If Mozilla is on board, why aren't the MDN docs moved over into it? Is MDN going to shut down and point everything to this? If not (likely), which are we supposed to be contribute directly to and do new contributions get ported to the other one?

I hope they have some full timers on this and they are masters of content strategy. This project will need ongoing content curation more than anything.

Responsive Web Design Weekly

This email newsletter by Justin Avery is a good way to keep up with all the latest news, implementations, techniques, and what-have-you with the biggest web sea change since CSS.

Web Developer Economics: Monthly Service Costs

Dave Rupert once asked people on Twitter about all the web services they paid for and it looked like he received a lot of interesting replies. I thought I'd blog mine and get the ball rolling on sharing lists of these services. It's interesting to consider the apps that have managed to cross our magical barrier to our pocketbooks. Perhaps looking at them as a whole we can see a pattern or at least have better mental grasp on our spending choices as developers. The following is a list of every web developer-y web service I personally pay money for.


CSS-Tricks Chronicle VI

That Twitter Cards thing I mentioned in the last Chronicle worked out. You can now see "View Summary" links when someone tweets a link to CSS-Tricks, which when clicked provided some extra context to the article.


All I had to do was turn on the checkbox to add the meta data via the WordPress SEO plugin and apply on Twitter.

BD Conf was pretty fun. I love the gigantic Gaylord hotels they are at. My new talk went pretty well. The workshop went OK but it was no masterpiece. I'm in a weird place where I'm stuck between wanting to take this as a personal challenge and work on doing amazing workshops or going the other way and stopping doing them.

ConvergeFL was also fun. I got to give the workflow talk a second time and it was a bit more refined. Now I'm back home for a few weeks before taking off again for Future of Web Design in New York. Will be my first time ever to New York.

At ConvergeFL, I attended a workshop on eye tracking by JD Graffam (and team) of SimpleFocus. Afterward we did an eye tracking study on CSS-Tricks. Four different people and ran through a script that took about 40 minutes for each person. I'll be sharing more about that as soon as I can.

I had to put pagination in at The Lodge because all the sudden people were reporting the main video list crashing their iOS devices. I suspect the same exact problem as documented here.

I also added a "Mark as Watched" feature for videos there, so you can tick them off as you watch them and keep your place.

157 videos have now been posted there. That's all but one, a final wrapup, which I hope to shoot and post soon.

I made a proper testing demo for using icon fonts and added it to this blog post. In my testing using VoiceOver on OS X Mountain Lion, the best way is still with a span and pseudo element.

I updated the Treehouse logo in the header to use SVG. I can do that because this site only supports IE 9+. I could have put in a fallback, but didn't have to because of that support level. This is just a friendly reminder that SVG is pretty awesome for vector art. More importantly, it's not weird or hard to use. You use SVG just like you would JPG, GIF, or PNG:

<img src="logo.svg" alt="Logo">


div {
  background: url(logo.svg);

I'm going to be speaking at Webstock in New Zealand this coming Feburary. The speaker list is different than the usual web design conferences I normally go to. Jim Coudal, John Gruber, Jason Kottke... whaaaa? Awesome.

I worked up a series of six media queries that handle a pretty common situation these days:

  1. Small screen not retina
  2. Small screen retina
  3. Medium screen not retina
  4. Medium screen retina
  5. Large screen not retina
  6. Large screen retina

It sparked a good bit of debate on Twitter, but is was a little out of context there. The big use case: delivering specific "hero" assets perfect for the occasion. Perhaps a large screen background image like The Lodge has. I'm not suggesting we fork layouts for these scenarios, but I am suggesting some intelligent asset delivery for them is a good idea, and you can begin to do through smart media queries.

Digging Into WordPress v3.4

Jeff Starr has updated our co-authored book to cover the new things in WordPress 3.4, update various content, and update the ALL AJAX theme that comes with it.

This is the 10th update to the book. Pretty cool that there are people that bought they book nearly 3 years ago now who are still getting free updates.

Custom User @mixins

Mixins are one of the most useful and compelling reasons to use a CSS preprocessor. The typical way they are presented is for helping with CSS3 vendor prefix stuff. Indeed that is a compelling use case. No more tedious writing of all the prefixes and even more tedious updating of them over time.

However, if you are using Sass, you can use Compass, and Compass already has all those CSS3 mixins ready to go for you. Want to use the new CSS filters but want to be all future proof about it? No problem:

img {
  @include filter(grayscale(100%));
  &:hover {
    @include filter(grayscale(0));

And you're good to go.

But handcrafted @mixins can be useful too! That is, @mixins that you author yourself to benefit your specific project. I enjoyed a post by Sacha Greif where he outlaid some @mixins he uses sometimes for specific projects.

For instance, he has some for the embossing & letterpress effects found on some sites.

@mixin box-emboss($outerOpacity, $innerOpacity) {
    rgba(white, $outerOpacity) 0 1px 0, 
    rgba(black, $innerOpacity) 0 1px 0 inset;

And then you could call that on any selector you wish to have that effect.

.module, header[role="banner"] {
  @include box-emboss(0.3, 0.6);

If you wanted to get super clever with this, you could also make a placeholder selector in which to @extend. That way you aren't repeating any code in the compiled CSS but you can separate your selectors and organize them however you want.

%box-emboss {
  @include box-emboss(0.3, 0.6);

header[role="banner"] {
  @extend %box-emboss;


.module {
  @extend %box-emboss;

Here's an example of that on CodePen:

I thought I'd share other custom @mixins I've used on some of my own projects.

Font Stacks

On this site I have four font stacks:

  1. Brand
  2. Headers
  3. Body
  4. Code

If you're properly careful with fonts, you probably aren't setting font-family too many different times in your stylesheet. If you're setting the same stack a dozen times, there is something wrong going on. But, you might have to more than once. For instance, you might have a default body font set literally on the <body>, but that won't cascade into form elements, so if you want to use the same font there you'll need to set that again on those elements. Now that you're setting it in two places, a @mixin is already useful.

I like using @mixins for this rather than a string variable set to the font families themselves, because the @mixin allows you to set other properties too if you wish. For instance, you might be using an @font-face font where you're only loading one particular weight and thus you want to set that weight whenever you set that font-family.

Here's the @mixins at the moment for this site:

@mixin font-stack-brand {
  font-family: 'Gotham Rounded A', 'Gotham Rounded B', "proxima-nova-soft", sans-serif;
@mixin font-stack-headers {
  font-family: 'Whitney Cond A', 'Whitney Cond B', "ronnia-condensed", sans-serif;
  font-weight: 700;
  font-style: normal;
@mixin font-stack-body {
  font-family: 'Whitney SSm A', 'Whitney SSm B', "ff-meta-web-pro", sans-serif;
@mixin font-stack-code {
  font-family: Menlo, "inconsolata", Monaco, "Courier New", Courier, monospace;

Media Query Mixin

You can create mixins that output the content that you pass after it in curly braces. This allows for a couple of neat possibilites. For instance, you can "name" a media query and then use it wherever you want. Meaning updating that media query only has to happen in one place. For instance:

@mixin breakpoint($point) {
  @if $point == mama-bear {
    @media (max-width: 1250px) { @content; }
  @if $point == baby-bear {
    @media (max-width: 800px) { @content; }
  @if $point == reverso-baby-bear {
    @media (min-width: 800px) { @content; }
  @if $point == reverso-mama-bear {
    @media (min-width: 1250px) { @content; }

And a simple usage example:

.page-wrap {
  width: 80%;
  @include breakpoint(baby-bear) {
    width: 100%;

.footer {
  a {
    display: inline-block;
    @include breakpoint(baby-bear) {
      display: block;

You can learn more about this idea here.

Example of this on CodePen.

Animation Mixin

Compass doesn't have a @mixin for keyframe animations yet, but this is very easy to add on your own. It uses the same @content idea that the media query mixin uses above.

@mixin keyframes($name) {
  @-webkit-keyframes #{$name} {
  @-moz-keyframes #{$name} {
  @-ms-keyframes #{$name} {
  @-o-keyframes #{$name} {
  @keyframes #{$name} {

And one to set the animation...

@mixin animation($value) {
  -webkit-animation: $value;
  -moz-animation: $value;
  -ms-animation: $value;
  -o-animation: $value;
  animation: $value;

Using it then becomes easy:

@include keyframes(move) {
  0%   { left: 0; }
  100% { left: 100px; }

.box {
  @include animation(move 0.5s ease infinite alternate);

You can learn more about CSS animation here.

Example of this on CodePen:

Toolbox Mixins

There are some simple helper classes that I've used on countless projects over the years. Things like an accessible hiding class and typography helping classes. If you make a mixin for these things, you can get double the bang for your buck.

// Accessible hiding
@mixin screen-reader-text() {
  position: absolute;
  top: -9999px;
  left: -9999px;
.screen-reader-text {
  @include screen-reader-text;
// Overflow Ellipsis
@mixin ellipsis() {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
.ellipsis {
  @include ellipsis;
// Word Wrapping
@mixin word-wrap() {
  -ms-word-break: break-all;
  word-break: break-all;
  word-break: break-word;
  -webkit-hyphens: auto;
  -moz-hyphens: auto;
  hyphens: auto;
.word-wrap {
  @include mixin word-wrap;

Now you have a class name you can use in markup if you need to apply these properties. But you also have a mixin you can use to apply these properties to other declarations if you can't or don't want to touch the markup.

Note that I generally don't advise having your mixins and classes right next to each other like this. I prefer mixins to be in a separate file like _bits.scss which compiles to nothing and thus can be included on any other Sass file.


It's always fun to share.

Live Weather Display Using CSS, jQuery and PHP

The following is a guest post by Darren Jamieson, the technical director for Engage Web, an online marketing firm in the UK. We fiddled around with this back in 2008, but I thought it might be nice to share an updated technique and Darren obliged with his work. This takes the idea to another level by combining the sun and moon and time of day in addition to the weather.

In 2006 I had an idea which involved displaying a live weather feed on a company’s website, using the Yahoo Weather API as the source. At the time however, the only way to do this effectively was by using Flash, and this was something the company was unwilling to do due to the development time involved.

Six years later, as the technical director of my own business, Engage Web, I revisited this idea for our newly rebranded company – and moved it on a couple of stages. In 2012, Flash was no longer necessary, as everything it could do in 2006 could now be done with CSS3 Keyframes.

We set out with ambitious plans to have our website feature the live weather conditions using the geo location from anyone who looked at it. We wanted the time of day to be reflected depending on where they were based in the world, so somebody looking at the website in London, England would see a different style to someone looking at the website at the exact same time in San Diego, California. The goal was that people could see what the weather was like outside their window by looking at our website.

Here are just a few examples of the final state the header of the site can look like at any given time:



Heavy Rain

Heavy Snow

Light Clouds

Mild Rain at Night

Mild Rain


Unfortunately, we ran into some immediate snags of a technical nature caused by the old nemesis of the web developer, Internet Explorer. IE wasn’t able to handle geolocation, so getting an accurate approximation of a person’s location from their browser wasn’t possible. Instead we had to use an IP lookup API to get the location of the user, which is only accurate to the user’s nearest capital city (or large city). For this we have used Based on the IP Address entered into this site, it returns the Country, State/Province and City/Town of the user. We only needed the Country and the Town/City, which is then fed into Yahoo’s Weather API, giving back live weather data for the area.

If no data is fed back from (for example if the website ever went down, or IP data couldn’t be retrieved from the user) the location is defaulted to London, England.

Both the Yahoo Weather API and feed back longitude and latitude, which is then used to calculate the sunset and sunrise times, which in turn trigger the sunrise and sunset on the website.

The final egg in the pudding is the moon phase, which was the most complicated of all the calculations, even though it required just the date as a variable.

Whether the Weather is Rain or Shine

Let’s start with the weather. Yahoo returns the weather information in the form of a number, currently between 0-47, with an error number 3200 for no information. Each one of those numbers represents a different weather type.

0  	tornado
1 	tropical storm
2 	hurricane
3 	severe thunderstorms
4 	thunderstorms
5 	mixed rain and snow
6 	mixed rain and sleet
7 	mixed snow and sleet
8 	freezing drizzle
9 	drizzle
10 	freezing rain
11 	showers
12 	showers
13 	snow flurries
14 	light snow showers
15 	blowing snow
16 	snow
17 	hail
18 	sleet
19 	dust
20 	foggy
21 	haze
22 	smoky
23 	blustery
24 	windy
25 	cold
26 	cloudy
27 	mostly cloudy (night)
28 	mostly cloudy (day)
29 	partly cloudy (night)
30 	partly cloudy (day)
31 	clear (night)
32 	sunny
33 	fair (night)
34 	fair (day)
35 	mixed rain and hail
36 	hot
37 	isolated thunderstorms
38 	scattered thunderstorms
39 	scattered thunderstorms
40 	scattered showers
41 	heavy snow
42 	scattered snow showers
43 	heavy snow
44 	partly cloudy
45 	thundershowers
46 	snow showers
47 	isolated thundershowers

We then split the weather types into four numbers. The first number controls the clouds, how light or dark they are and how heavy they are. The second number controls the rain. There are several degrees of rain on the website, ranging from light showers to heavy downpours. The third number controls effects, such as lightning or snow, and the fourth number is for incidental effects, such as dust or fog.

$weatherarray[39]=array('scattered thunderstorms',3,2,5,2);
$weatherarray[40]=array('scattered showers',3,2,0,2);
$weatherarray[41]=array('heavy snow',1,0,3,0);

One of the more common effects we see in the UK is rain (we get a lot of rain) so here is how the rain effect is done on our site. The below animated rain gif is displayed with a suitable opacity, depending on how heavy the rain is reported as being in the weather API from Yahoo. Our previous code takes the information from Yahoo and assigns variables for the rain strength, and these variables control the opacity of the animated rain gif in the below code.

switch ( $effect1) {
    case 0:
        $weathercode.= '
             jQuery(\'#rain\').css("opacity", "0.0"); 
     case 1:
        $weathercode.= '
             jQuery(\'#rain\').css("opacity", "0.10"); 
      case 2:
        $weathercode.= '
             jQuery(\'#rain\').css("opacity", "0.30"); 
      case 3:
        $weathercode.= '
             jQuery(\'#rain\').css("opacity", "0.50"); 

Full Moon, Half Moon, Total Eclipse

The most difficult part of the whole process was the moon phase. To do this we created a large image displaying 10 different variations of moon phase. The CSS then decides how to display the correct image based on the data fed back from a PHP script (the calculations for which are, quite literally, astronomical).

background-position: <?php echo $moonbgimagepos; ?>px 0;


The script to calculate the moon phase was derived from code which can be found here.

300 seconds to Sundown

The pièce de résistance of the project is the sunset and sunrise effect, which happens depending on the actual sunset and sunrise times at the location of the person looking at the website. Using the longitude and latitude we have previously mentioned, the sundown and sunrise time (depending on whether is currently day or night) is extrapolated, converted to a unix timestamp, and stored as a variable.

The current time is also converted to a unix timestamp, and the difference between the sunset or sunrise time and the current time is applied as a timeout to a jQuery function which handles the transitions between day and night, and vice versa.

The following jQuery controls the transition between three stages. For sunset the ‘daytime’ background is faded out, and is replaced by an orangey glow background (used for sundown and sun-up) which itself is then faded out into a night time background. While this is happening, the sun itself begins its decent from the top of the page to the bottom, which takes 300 seconds to complete.

jQuery('#daytime').fadeOut(200000, 'linear', function() {

  jQuery('#sill').fadeOut(100000, 'linear', function() {});

  jQuery('#sunset').fadeOut(100000, 'linear', function() {});

While this is occurring, any relevant weather effects are also overlaid on the screen, such as rain, snow, lightening and cloud movement. As an added effect, the skyline also transitions from a day theme to a night theme to show the buildings descent into darkness, and the city lights come on.

Working Day and Night

As an added effect, the additional style elements of the website, such as colouring effects, are changed depending on whether the is time is day or night. This is done by using a PHP file as CSS once the variables have been established.

<link rel="stylesheet" type="text/css" href="/css/styleweather.php" />

If you happen to catch the website while the sun is setting or rising however, you see the skyline and site theme change as the day transitions to night, and vice versa. The following code controls this using jQuery:

jQuery('#backmask').animate( {
    color: '#fff',
    backgroundColor: '#48508b'
    },300000, 'linear' );
jQuery('#menu-top-menu li,#blogmenu,#searchbox, #times').animate( {
    color: '#fff',
    backgroundColor: '#48508b'
    },300000, 'linear' );
jQuery('#Phone').animate( {
    color: '#fff',
    backgroundColor: '#48508b',
    boxShadow: '0 -10px 10px 4px #2A3160 inset'
    },300000, 'linear' );

Testing, Testing, 123

When building something which is triggered by the sunset and sunrise times derived from the longitude and latitude of the user, testing the effect was a mission in itself. This required working out where in the world the sun was about to rise, and then connecting to the website via a proxy server in that country to check the timings. We learned a lot about geography, time zones and sunrise times working on this project!

Here's a screenshot of the website with the effect working:


Credit to designer/developer Steven Morris for the design work on this project.

Notes from my BD Conf Workshop

Just a few days ago I gave a four hour workshop at BD Conf in Dallas, Texas. I thought I'd round up the notes from it to give to the attendees. And I also thought it might be useful to post publicly so everyone could benefit. Some of the stuff might not make much sense if you weren't there, but hey, that's the huge advantage of going to these events!


Receding Background Modal Boxes

You all know Hakim El Hattab right? He creates some super crazy progressive demos over on his blog. His CodePen profile is full of amazing too.

One recent creation of his is Avgrund. It's a design pattern for dialog boxes in which the main page fades away and the modal box flies down from above (or up from below). The main page becomes smaller and blurry, making it seem further away ala depth of field in photography. The modal box sits on top, making it seem closer to you and clearly demand your attention. That's good, because the very purpose of modal boxes is to require a user to give you some input before they can do anything else.


It feels pretty magical when you see and use it. Kinda makes you want to right-click and see if it's Flash. But it's not, and like many things on the web when you start digging in, the magic is just a nice combination of simple effects.

Let's look at them in order. Note: this isn't exactly how Avgrund works, it's just me reverse engineering it.

Step 1) Separate Page Markup and Modal Markup

All the content on the entire page should be contained within a wrapper div. The modal is outside of that wrapper.


  <div id="page-wrap">
    <!-- all page content -->

  <div id="modal">
    <!-- modal box content -->


How that markup gets there is up to you. If I was using this for real, I'd probably inject it dynamically when needed through a JavaScript thingy I create just for handling dialogs.

Step 2) State Based CSS

No need to get too fancy with JavaScript. If we think "state based", all we need is a class name on the body element and we can adjust all visual design as needed with that class. This is a larger concept that is useful in big ways and warrants further discussion (like how/where/why to trigger states), but let's just keep it simple here with a bit of jQuery:

// Something happens
$("button").on("click", function() {

  // State changes


Step 3) Default State for Modal

The modal will be a fixed position box right in the middle of the screen. By default, it will be hidden (zero opacity) and unclickable (pointer-events). Let's just ignore browser support on that. If it's a big deal to you, you can hide it in any number of different other ways like positioning it off screen.

#modal {
  background: white;

  position: fixed;
  width: 50%;
  top: 50%;
  left: 50%;
  margin: -25% 0 0 -25%;

  /* Embiggen */
  transform: scale(1.5); /* prefix me */

  /* Hidden */
  opacity: 0;
  pointer-events: none;

Step 4) Active Modal State (The Magic!)

Now we have all we need to "recede" the page when the modal is open. Let's target the #page-wrap when the state is active and do the magic.

The magic is simply: transform scale the #page-wrap to make it smaller and filter the #page-wrap to make it blurry and less colorful.

.dialogIsOpen #page-wrap {

  /* Blur and de-color */
  -webkit-filter: blur(5px) grayscale(50%);

  /* Recede */
  -webkit-transform: scale(0.9);


WebKit only? Well... the filters are only in WebKit for the time being. Your call if you want to load up the vendor prefixes or not. If I was going to use this for real on a site, I'd spend a little time making sure this effect had a fallback, which shouldn't be too hard. Perhaps just an emphatic box-shadow would do.

Then: Make the dialog appear from above, enforcing the depth of field effect. Opacity makes it appear; transform scale makes it appear from above.

.dialogIsOpen #modal {
  /* Regular size and visible */
  transform: scale(1); /* prefix me */
  opacity: 1;

  /* Clickable */
  pointer-events: auto;


Step 5) Transitions

To make it feel natural and magical, toss in some transitions on both of the players involved.

#page-wrap, #modal {
  transition: all 0.4s ease; /* prefix me */


Of course Sass/Compass makes all this a bunch easier since it has @mixins for all this stuff. e.g.

@include transition(all 0.4s ease);
@include filter(blur(5px) grayscale(50%));
@include transform(scale(0.9));

Fair warning, this stuff is fairly memory/processing intensive. Sometimes little hacks like triggering 3D transforms helps in WebKit, at the risk of nasty looking text.

body {
  /* Use at your own discretion */
  -webkit-transform: translateZ(0);


A video, if you don't have access to a supported browser or whatever:

I put my reverse engineered demo from this article on CodePen, but you should really just go look at Hakim's demo, which also on CodePen.


Paul Irish:

The past few years’ browser focus on speed has been great for us and our users. We’ve seen a huge and dramatic performance boost on benchmarks like Sunspider, Kraken, and Octane. But, these benchmarks, often crafted by JavaScript VM engineers, test raw JavaScript performance, which is rarely the bottleneck we have in our apps.

There is a new kid on the block for testing browser performance that testing things that developers actually care about.

CSS FilterLab

Little one page tool from Adobe for playing with filters (blur, grayscale, brightness, etc). Filters are working in stable Chrome and Safari 6 now. I predict filters to be a huge trend in 2013 as browser support grows and designers start figuring out what kinds of interesting/effective things they can be used for.

CSS-Tricks Chronicle V

You can now use Markdown anywhere you would write something on CSS-Tricks, namely the comments section here on the blog or when creating or replying to threads in the Forums. I like it. I think it makes writing comments much quicker and flow nicer, rather than being interrupted to go back and add actual HTML anchor tags when making a link (which often leads to just pasted URLs) or for making lists (which almost nobody ever does, they just write the bullets or numbers right in the text).

I've now published up to video #75 in The Lodge. That's about half way done. I said it would take me a month to get them all done and it looks like that will be just about accurate. It takes a while because I don't just upload the video and be done with it, I also write up notes that go along with each video that include further thoughts and relevant links.

Speaking of Lodge videos, I'm enjoying the comment threads happening on those videos. Comment threads here on the blog are pretty good too in general, but the slower pace and more thoughtful (some long-form) comments happening in Lodge videos are fantastic.

Also speaking of comments, you can now leave Pens from CodePen in comment threads for blog posts on this site. See the comment thread on this post. It doesn't work on just any site's comment threads because it requires a <script> to work which usually (rightly) gets stripped from user generated content, but I load that script on this site.

I'd really like to get Pens working in forum threads. It should be easy, the problem is that Markdown in the forums is stripping the data-* attributes off the <pre> tags in the copy-and-paste code we give you from CodePen, which are required for it to work. Not sure why this happens in the forums but not on the blog. If anyone has any ideas, there is an open forum thread.

I take off this Saturday for Dallas, Texas and BD Conf where I'll be giving a brand new talk and workshop. I don't usually get super nervous for talks unless it's brand new material for a discerning audience, and, yep. I'm just going to have to practice more.

After I get back from that I'm only home a few days before I'm headed to Tallahasse, Florida for Converge FL. I'll be giving a talk there as well as doing some eye tracking studies for this website with a real eye tracking machine.

Using LESS as a Live CSS Engine

The following is a guest post by Andrew Powers of PageLines. Andrew wrote to me about how they use LESS in their product and how they think it's better than Sass for what they do. In complete honesty, I still disagree (they are using an unofficial PHP port of LESS, and there is an unofficial PHP port of Sass also), but I can't argue that they way they use it is pretty cool and works for them. This is Andrew explaining that.

There has been a lot of talk recently about using LESS/Sass as preprocessors for creating cleaner, cross-browser friendly CSS faster and easier than we could before. And from my own experience I can tell you that once you go to one of these languages, you’ll have so much fun that you won’t be going back to plain CSS.

The problem with these languages, however, is the word ‘preprocessor.’

The idea of a preprocessor is there is this ‘processing’ step between the code you write and the code you use on your site. That’s kind of a hassle. Also it prevents us from using variables or functions dynamically, which might be useful if you have users customizing the presentation of your code (like in a WordPress theme).

Well, live processing LESS in production is very possible, and here is how we’re using it to solve some big problems at our company.

About PageLines


PageLines makes a ‘drag and drop’ framework, built on WordPress, intended to make building professional websites easy.

Trying to keep the professional, yet easy (typical users shouldn’t have to write *any* code), has created a few engineering challenges which LESS has helped solve.

Use Case

The PageLines framework is built on WordPress (in PHP). In considering this solution we had several goals. For example, we wanted to:

  • Allow CSS to be customized based on user options inside the framework
  • Organize and compartmentalize CSS better without upping performance killing HTTP requests
  • Create better, more cross-browser designs, faster and easier without having to deal with a new ‘preprocessing’ step in our workflow

Why LESS for Live Processing? (Not SASS/Compass)

Chris wrote an interesting article on the merits of Sass vs. LESS. However, there are a couple thoughts left out that shift things in the favor of LESS for live processing for us. Specifically LESS was designed in JavaScript, the developer friendly language, and was also created to be used live. Most importantly, it compiles 6x faster than SASS. Jacob Thornton, architect of the popular Bootstrap by Twitter, has some more input on the debate here.

While the original live less.js approach has too much of a delay in production, it still helps seal the deal for LESS when we’re talking about using it in production instead of as a preprocessor. We ultimately used a special PHP port of Less.js to accomplish our goal, more on that in a second.

As a sidenote, it’s theoretically possible to use SASS ‘live’ if you’re developing in a Ruby on Rails environment. We haven’t actually tested this, so I’m not sure about the performance or bottlenecks using that approach.

How we implemented it

For us the the key to executing a live LESS engine was this port of the LESS processor to PHP (link) which allowed us to parse and cache LESS files based on user action on our server. To get this working the framework just does the following.

  • Grabs all the LESS files throughout the framework and adds them to a PHP variable
  • Uses the above PHP script to parse the LESS into CSS and puts it in a variable
  • Outputs the CSS to a file which is cached both on the server and on visitors browsers
  • The process is run again whenever a user saves their settings or installs a new extension

Code Example

This isn’t the actual code we used, but should give you a general idea.

$parser = new lessc(); // Start new object from PHP Less script
$less_code = file_get_contents(‘/path/to/whatever.less’); // Grab LESS
$processed_css = $parser->parse($less_code); // Process to CSS
file_put_contents(‘path/to/css-file.css’, $processed_css); // Write CSS
echo “<link rel='stylesheet' href='http://url/to/css-file.css' type='text/css' media='all' />”; // Link CSS in page



Changing background color in the framework. Highlights and contrast element colors are calculated using LESS.

Control - Dynamic Colors and Typography

One of the coolest things about implementing LESS inside of the framework is that we’re able to dynamically control colors and typography based on user selections. This allows us to design things well, while still giving users the ability to customize colors and type.

Options - LESS Option for Users


Users are able to actually add their own LESS in the admin options panel. They can use common variables for the background color or main fonts. This has been a feature that users love and can use to create more cross-browser, robust customization of the framework.

Organization - Several Files Into One


Using a processor for the LESS allows us to have all our css/less files organized by type, then grouped together at runtime into a single ‘compiled-css’ file. Definitely makes it easier to find what we’re looking for.

Optimization - Cleaner, Faster, Cross-Browser CSS


Because we can use nested selectors & mixins the code we are writing is much cleaner. While this is the same as when using a preprocessor, not having to deal with finding all the files and compiling allows us to use this without the hassles.


Open-Dyslexic is a new open sourced font created to increase readability for readers with dyslexia.

#Lazyweb: They have an iOS app, but someone should make a bookmarklet to swap out the font on page with this font for desktop browsers. Or browser extension(s). Update: all of which now exist on the downloads page.

via Instapaper Blog

Responsive Measure

A jQuery plugin by Josh Brewer and Mark Christian that adjust the font size based on your ideal line length to keep a consistant typographic measure across all screen sizes. Kinda like FitText.js but for use on body copy. The new vm/vh units may obsolete this, but not with the same simplicity.

WordPress Plugins I Use

I think this is a fun and useful style of post that any WordPress blogger can do. It's always interesting to hear in what ways people are extending what WordPress can do out of the box. I'll share the ones I'm using here on CSS-Tricks then you can share yours (either in the comments or in a post on your own WordPress site). My list is quite a bit different than the last time I did this in 2008. If you have some better alternatives to the ones I'm using, I'm always interested in that, too.


Rundown of Handling Flexible Media

When you take the responsive web design route, part of the deal is fluid grids. That is, container elements set in percentage widths. Just one example: an <article></article> that holds a blog post might be 320px wide on a small screen device and 690px wide on some large screen. Text can be resized and will flow nicely to fill a container. That's not too hard. But media - images, video players, and audio players - demand a bit more attention (e.g. a video that sticks off the edge of the screen == bad). This post is to round up the methods of handling that.


Preprocess THIS!

Allison Wagner shares her thoughts after 10 months of working with a CSS preprocessor. Many of the thoughts resonate with my own. On variables:

What I love most about them is they force consistency across the design system.

Being DRY is cool, but it's more about saving you from yourself. To me, it makes CSS fun again instead of tedious.

CSS-Tricks Chronicle IV

I had a weird problem this week where some mobile devices just weren't picking up on some CSS that was clearly linked to and loading on the vast majority of other browsers. It wasn't user agent based (I tried faking it). It wasn't screen size based. It was the device itself somehow. Turns out, I'm an idiot. I was doing this to @import the CSS:

@import "css/style.css";

Because, that's how you do it in Sass or LESS. Turns out that actually works in CSS in most browsers, but it's incorrect of course. This is correct:

@import url("css/style.css");

I could have fixed it by doing it correctly, but instead I fixed it by not using and @import which is pretty much always bad. Much better to get the CSS right in that stylesheet.

Update: Not using url() is valid per the spec, but tell that to some mobile browsers! (Thx Tab Atkins)

I've been bug fixing galore all week on this new design and I suspect there are many more weeks to come where most of my day is improving this design.

I turned on Twitter Cards data (about), as part of Joost De Valk's awesome SEO Plugin for WordPress. We'll see if they start working, that'd be kinda neat. I still think Twitter is awesome even though this is sad to me.

I've been spending my evenings preparing my brand new talk and workshop for BD Conf. They are both going to be about "A Web Designer's Workflow" and draw heavily upon my recent experience redesigning this site.

I changed over the video hosting for The Lodge videos over to Vimeo Pro. I'm hoping it is basically faster, provides a nicer player, supports more devices, and all while staying very high quality. The only hitch in the giddyup so far is that the Vimeo player is having trouble on the Kindle Fire and a few other Android tablets. I'm hoping this can be worked out.

CodePen is now on some big new fancy servers thanks to Tim Sabat, our server guy. In theory these bad boys will be scaleable for us forever.

Opt-Out Responsive Design?

Reader Glynn writes in:

I'm wondering if you'd ever seen a responsive web design in which a 'see full site' link was included. I know that when developing a responsive design we should stay away from hiding content completely, however some users may actually prefer pinching and zooming and using good old fashioned horizontal menus on their devices.

Have you seen an example of this and how do you think it could be approached?

I think this is a pretty darn interesting question.

There was a time when we jousted any site with a mobile version that didn't give us a "full site" link. But with responsive design taking hold, we're seeing a lot less of that. In fact I'm not sure I've ever seen it on a site that uses responsive design exclusively to accomodate mobile screen sizes.

Why don't we see opt-out responsive design? My guess is two-fold:

  1. It's a bit technically challenging to implement and there aren't a lot of precedents.
  2. It's admitting you didn't do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren't sure it's a better experience?

A possibly-legit situation is different use cases for different users. Perhaps most users come to the site to read and your responsive design accommodates reading very well. But some users come to do some other task and to them the responsive design is hindering.

Doing it

I haven't actually done this, but theoretically this is how I would. This will be easier if you've gone with a desktop-first approach rather than a mobile-first approach (I would think).

1. Query param to swich


2. Remove viewport meta and class the body

Then you test for that param. I'll use PHP here just because but it could be anything. We'll only remove the viewport meta tag if they don't want responsive design, as well as put a class on the body.


   <title>My cool site huzzah</title>

     if (!$_GET['resp'] == 'no') { ?>
       <meta name="viewport" content="width=device-width">
   <?php } ?>


<body class="<?php if (!$_GET['resp'] == 'no') { echo "resp"; } ?>">

You'll probably want to get a little more complex here. You'll want to set a cookie (or perhaps use localStorage) to remember the users preference. Then you don't just test for the query param but also the value of that cookie before making the decision to exclude the viewport meta or not (and the body class).

3. Qualify your media query styles

One way to do this would be to exclude the loading of a separate stylesheet where you have all your responsive styles. That might work for you but I'm generally a fan of keeping as much CSS together in one file as possible. If you do keep it in one file, you can use that "resp" body class to ensure media query styles don't take place if they shouldn't.

.page-wrap { width: 80%; }

@media (max-width: 600px) {
  .resp .page-wrap { width: 100%; }

This way the responsive style will only take hold if the media query matches and the proper class is on the body indicating it's OK to use responsive styles.

4. Have good UI to switch between

Whatever you cook up, make sure it's pretty clear how you get back and forth between the two site styles and that it sets the cookie stuff properly.