ZURBlog is where we discuss product design, business and strategy.

A month ago, we finished our initial efforts of redesigning ZURB.com. It took a lot of work and we had to overcome many challenges, but the outcome is totally worth it! We now have a site that we’re proud of and that does a great job of telling our story, sharing our beliefs and showcasing our work.

Our beliefs are told through the ZURBmanifesto, which outlines the core values of our company in a clear and concise way. it’s used to shape how we do business from every angle.

One goal we set for our new site was to showcase our Manifesto in a way that would get people excited when they stumbled upon it. We made sure the page looked like it had the same visual language as the main site, while also standing alone.

By looking at a single slide, you can tell that this is a ZURB page. We used color, typography, sketches and iconography to add dimension to the slides (both visually and metaphorically). To accomplish all of this visual candy, we used and abused CSS and jQuery a bit. We’re going to focus mainly on the CSS side of things for today. Follow along as we take a miraculous journey into the source code of our Manifesto.

The Manifesto features all the colors from the ZURB palette.

Capture Attention Quickly

We really wanted the transition between each slide to be memorable and eye-catching. We used multiple backgrounds that changed position as the user scrolls down the page, creating an effect of depth and movement. We also used sketches that were specific to each section to help add to the story in a visually fun way. These were animated, but aren’t affected by scrolling, just triggered by the position of the scroll bar. This way, they act as little surprises that reveal themselves in a unique way for each slide, even if the user stops scrolling.

To create the animations, we used CSS transitions that were triggered at different times by injecting new values via jQuery at specific increments on the page. The challenge was that we needed to constantly know the size of the screen, even if people resized it in the middle of their visit. This required lots of JavaScript to get right, but the CSS was relatively simple.

We made a container for each animation that had a fixed height and width based on the window size. The sketches were positioned within these containers and moved around by changing values with jQuery. The trick to making the sketches actually move was using only a few lines of CSS:

// A basic transition effect written in CSS
.animation-container img {
  -webkit-transition: all .3s ease;
  -moz-transition: all .3s ease;
  transition: all .3s ease;
}

To handle a lot of the animation states, timings and positions, we had to rely on jQuery so that we’d be able to know the window size and calculate our positions and timings accordingly.

Blur the Boundaries of What You Thought Was Possible

Another key factor in making the transition between each slide look and feel really awesome was how we handled the main text. As you scroll down the page, each slide overlaps the previous one, adding to the illusion of depth. At first, the text just stayed still, but it needed something more. We fiddled around with a couple ideas and decided that making the text fade into the background as if it was moving on the z-axis of 3D space would be best.

Resizing the text to make it look like it was fading into the background was pretty easy, but we really wanted to sell the illusion by making the text blur as well.

You can see how the text slowly gets smaller and blurrier.

Sizing the Text

To handle the effect of resizing the text as the user scrolls down the page, we strapped on our good ol’ CSS transform tool belt and its friend jQuery. Styling a static piece of text is simple with a transform, but we needed some logic to handle the change in size based on scrolling.

// A basic transform effect written in CSS
.scale {
  -moz-transform: scale(.5);
  -webkit-transform: scale(.5);
  transform: scale(.5);
}

// Written in jQuery, using a variable to change the scale
$blur.css({
  '-moz-transform': 'scale(' + blurScale + ')',
  '-webkit-transform': 'scale(' + blurScale + ')',
  'transform': 'scale(' + blurScale + ')'
});

We created an equation that outputted a percentage (blurScale). This percentage would change as the user got closer to the next slide. Now we had our text scaling and partially looking as if it was moving in a 3D space.

Blurring the Text

The blur effect in the manifesto isn’t really a blur at all, it’s text that has the color attribute set to transparent and the text-shadow attribute set to different amounts. The higher the spread of the text-shadow, the more blurred the text would look. We employed a similar jQuery technique to handle the logic we needed to change the blur effect as the user scrolled.

// CSS Needed to create the blurry text effect
.blurry-text {
  color: transparent;
  text-shadow: 0 0 30px rgb(255,255,255);
}

Our JavaScript simply changed the “30px” value depending on how close the text got to the next slide to create the awesome blur effect that is shown.

Design For Any Device

With the number of devices being used to surf the web these days, we just couldn’t pass up the opportunity to make this puppy responsive. We utilized parts of the Foundation grid, jQuery conditional statements and media queries to render different effects and layouts at different screen sizes. One of the concerns we had was performance. Mobile devices aren’t known for handling lots of animating objects happening at the same time. This has to do with how they handle the code and the size of the load.

To ensure that people viewing on mobile devices had a good experience, we removed most of the fancy JavaScript effects and made the slides stack down the page in their normal flow. The animated images were made static and the backgrounds simplified. We wanted it to be easy to flick down the page without performance slowing people down. The changes were handled using media queries.

// Media query example
@media only screen and (max-width: 768px) {
  .row { 
    overflow: hidden;
    padding: 0 20px;
  }
  …
}

Venturing Into New Territories

We had our heads down in the code on this one for awhile, but we’re really happy with how it turned out. It was a new type of responsive challenge for us, handling such complex animations and logic while mixing so much CSS and jQuery. The parallax effect of the page helps to add excitement to our beliefs and conveys them in a unique and creative way. Sometimes the best way to teach yourself a new technique is to just jump into an idea full-force and not think about how hard it might be to complete. There are always solutions, you just have to find them.

You can take these techniques and come up with something awesome too. Be sure to post it in the comments for everyone to see. The best way to push boundaries is to venture into new territory and let others challenge your assumptions. Take risks and run with your ideas.

Check out the ZURBManifesto »

We looked at the current state of responsive tables, and we weren't happy. Today we've released a new playground piece, with a new, awesome take on responsive tables.

If you've ever tried to make large data tables work in a responsive design, you know what a pain they can be. Tables have a magical property that says they can never be so small that parts of a word have to be cut off — they can't overflow. That means that, when your design shrinks down for the width of, say a smartphone, large data tables will ensure your design doesn't actually shrink all the way down. It sucks.

We wanted to try and do better, so we got to work on a responsive table implementation that would meet three criteria:

• Doesn't break responsive layouts
• Doesn't unnecessarily hide table data
• Still allows you to compare rows with a key column

A bit of a tall order but with some crafty CSS/JS, we cooked up something we think is pretty nifty. You can go ahead and check out our new responsive tables, or stick around to hear more about how it works.

How it Works

As we looked at tables we realized that, most of the time, the first column is the unique key for a table. That provides the reference for the other columns, while the column headers provide the legend for what everything means. With that in mind, we wanted our responsive tables to have that first column available at all times.

This is a schematic of how the table changes from a larger screen to a small one. Basically, we take the first column and pull it out of the table element, positioning it over the table in its own element. Then we allow the table itself, minus that first column, to scroll under it horizontally.

What this allows is for the user to see the entire table (albeit not all at once, they have to scroll) while still seeing that first 'key' column. We don't have to flip the table axes, or hide data, or break the layout, we just rely on the user's ability to swipe across to see all the data and compare the rows and columns.

There are a couple caveats here. First, for the small device format we have to restrict cells to a single line (for a consistent height). The separate left-hand column and other column elements don't impact each other, so they can't correctly dictate an arbitrary height. Second, this doesn't work in Android 2.3 and below as it doesn't support scrollable DIVs. Android 3+ should be good to go.

Built for Foundation

We developed these to drop right into Foundation, our responsive, open source front-end framework. They're great if you're working on a responsive prototype, or responsive production code, and need a way to manage large sets of tabular data. While they're built for Foundation, they should work in any responsive front-end.

Try it out, give us feedback

You can check out our responsive tables or you can go right to the code on Github.

If you're interested in other approaches, Chris Coyier did a great round-up a while back on responsive data tables — there are some fascinating approaches in there, but none which met our criteria.

If you have some other ideas to either improve on this approach, or something else we should check out, sound off in the comments. Have fun with this new code, it was fun to work on and hopefully fun for you to use!

If you hadn’t heard, bigger monitors are in, small ones are out … at least for desktops. The 1366x768 has ousted 1024x768 as the supreme screen size. Now we hope you’re not thinking that means we should stop designing for small screens, even if it is for desktops, despite what Jakob Nielsen might be saying. Because when it comes to designing for the web — size shouldn’t matter.

Nielsen makes it a point to carefully say that “small screens are finally so rare for desktop computers that we don’t have to design for them.” Then he goes on to cover his bases, saying we still have to consider small screens anyway. Nielsen seems stuck in a desktop world, a single-device myopia. When it comes to mobile devices, Nielsen seems to begrudgingly consider them and lays out these option:

• Build a separate mobile-optimized site: Only if you have the time to do so, then auto-direct them to the site and provide the appropriate links to toggle between the full-blown site or the mobile site.
• Mobile apps might be better: That’s because studies show that users perform better on mobile apps, says Nielsen
• Design for smaller tablets separately: Full-blown sites look good on 10-inch tablets, such as the iPad. Ideally, says Nielsen, you’d want to design a third option optimized for mid-sized devices, like Amazon’s Kindle Fire.

That last bit of advice seems really foolhardy. We can’t ignore that more and more people are using mobile devices to access the web, be it for tablet or smartphones.

Nielsen does make some good points about larger screens (like optimizing for widescreen monitors around 1,440px wide), something we considered when it came to images for the new ZURB.com homepage. But like 960 grids, we can’t get stuck in one screen size or device.

Four Corners, Not Devices

Don’t get us wrong, we agree with Nielsen that the desktop is far from dead. Tablets and phones are very much consumption devices (for now). It’s very easy to say that mobile will kill the desktop or the laptop as we use our mobile devices more and more everyday. When it comes to writing long pieces or editing/writing code or text, desktops are still where it's at.

For the time being, we’re still going to use a variety of devices for different tasks. It’s not devices, however, that we’re designing for — it’s four corners, no matter the size.

So it’s a waste of time to develop sites specific to each device. What’s needed is a modern grid system, which is why we developed Foundation and why we’re on the road to Foundation 3.0. Once completed, it will be one of the most, if not the most, modern responsive grid system in the world.

The Road to Foundation 3.0

We’ve already released a taste of Foundation 3.0 and another taste is planned for later this week. But what does it take to build a modern grid system that meets the challenge of building a robust site and still look good on hundreds of different devices and browsers?

In other words, what is it that we need in a modern grid system. Let's take a look:

• Flexibility: There needs to be enough columns that covers the majority of our layout requirements.
• Nesting: We have to have something that can nest down into a single column, right down to the N levels to give us the flexibility we need.
• Responsive: Since we’re no longer designing for devices and designing for four-corners, no matter the size of the screen, our grid needs to be responsive, fluid (percentage-based) and configured to scale down to smaller devices. And a fluid design is something even Nielsen sees as a good thing.
• Modifiable: Modifying things such as gutter size are a pain in the butt. So we want something that’s modifiable.
• Backwards compatibility: That’s because not everyone in the world uses Chrome or iOS5 Mobile Safari. We’d need support for Android, iOS 4+, Webkit browsers, Firefox and IE8+.

Here’s what such a grid would look under the hood (take a close look, it’s a sneak peek under the Foundation 3.0 hood):

OK, this looks great for desktops, but for smaller devices, we’ve added additional styles wrapped in this media query:

But there’s some overriding we have to do, to basically tell the browser on a small display to: don’t float the columns, don’t give them a min-width, don’t give them margins:

There’s more to building a modern grid system than just these two bits of coding. In fact, Jonathan goes completely under the hood to show us step by step on how to build such a grid system in a recently published .net Magazine article.

When it comes to being a responsive designer, remember what Yoda said, “Size matters not.” What say you?

Our old homepage.

Today we're super stoked to relaunch our ZURB.com homepage. Over the past three years, we've been tinkering and making changes across ZURB.com. We rebooted our blog and launched our ZURBapps page. But our homepage was a bit neglected. The homepage needed to make a bold statement. It had to scream ZURB.

Not just in terms of visual design. It had to scream what we're all about at ZURB — helping people design better for people. We've been working hard at streamlining our message, even going back to our roots with product design. So we had to make sure we communicated that across all our pages. The new homepage also had to better showcase our work and our team.

In so many words, the old site was trapped in the past, stuck in the antiquated 960px grid while the rest of our work was moving more and more toward making sure our designs looked good on any device. We have been moving over a lot of our sites to Foundation and wanted to make sure our new homepage got a piece of that action.

From Sketches to Prototypes

Some of our early sketches.

Like everything else we do, we started with a few sketches to get our opportunities out on paper. From there, we even created some lo-fi sketch wireframes to get a feel for how the site would flow.

Through that exercise, we discovered that longer pages would work much better than splitting up the content into many different pages. The web is moving more and more toward longer pages. That's because people tend to scroll through web pages mimicking how they would view a page on a mobile device. We also didn't want people jumping around the site when accessing it on mobile.

We then moved into a coded prototype using Foundation. The prototype went through a few iterations, with each one exploring ways to consolidate sections and add more of our ZURB personality. On our third iteration (third time's a charm!) we had many rounds of feedback on Notable. Click on the picture below to check out one of our many rounds of feedback:

We then created four visual designs from there with each designer taking a shot at how they felt the new ZURB.com should look and feel like. It's fascinating to see how the same content can be transformed in so many ways. Check them out by clicking the images below or on this Influence preso:

Variation One

Variation Two

Variation Three

Variation Four

We decided to go with Variation Two as it created the nice, big impact we wanted. The design had that wow factor we were looking for with the large photo. Everyone seemed to gravitate more toward this design and presentation.

Containing the content also stood out in this design. It was something we hadn't done on the previous homepage. But putting the content in a container made the picture at the top pop out more. It gave the image a much bigger impact. Adding colors on the page also helped make all the pages seem more cohesive.

Additionally, the design incorporated sketching. This showcased one of our design methods and also put the design more inline with our other pages, like our ZURBapps. We also wanted to create more glyph-like icons to also further connect the page visually with our other properties.

Built ZURB Tough For All Devices

Not only did the visual design add more icons and sketches to showcase how we work and what we believe in, we also busted out the camera and took tons of pictures around the office. That’s because we wanted the new page to focus on people and product design.

Our site is also broken up into different sections — such as the homepage, the about page, the team page — with a nav bar that lets you easily navigate between them and our different properties.

We kept the pages as one long running page for one page load. This meant that you didn’t have to jump around to see what’s new on the page. Bonus: being built on Foundation meant it looked sweet on smartphones, tablets and desktops.

Not Without Its Challenges

The new rebuild wasn’t without a few challenges. There were problems using full-width images at the proportions we wanted. It took a few impromptu photo shoots, but we found a few that worked nicely. We plan on rotating the images throughout the year, so be sure to check back often.

But enough of that — poke around the new site and let us know what you think in the comments below!

Visit The New ZURB.com

Last week, we announced that Verify now supports mobile testing, a very exciting milestone for us and something we feel is absolutely mandatory in our multi-device world. But when we decided we needed to support mobile testing in Verify, we couldn't just snap our fingers and make it work. First, we had to determine how we would implement for mobile in our app, with its existing codebase and styles.

We gotta admit that we were extremely proud of the look and feel of the Verify tests when we initially designed them. We wanted them to be fun to take, simple and very fast. That's why we wanted to keep the same visual presentation, as well as the simplicity and speed, when it came to making them responsive. That meant not discarding all of the design and making sure that survived the transition.

Enter Foundation

Verify was actually built on top of a precursor to Foundation called the ZURB Coded Style Guide. While that wasn't responsive, or even particularly full-fledged, it did mean that adapting our tests to the Foundation syntax was relatively simple. In lieu of fixed test screen containers, we went to flexible, fluid containers. Instead of using absolute pixel positioning, we positioned things based on percentages or floats so they can scale down gracefully.

Adapting the Verify test screens to Foundation was actually pretty quick work. But there was some complexity with the interactions that we resolved on a test-by-test basis. Check out a few of these sample test on your mobile and you'll see the level of refinement you should bring to sites or apps that you change over to a responsive design.

Responsive Isn't Just Layout

The Verify annotation test allows testers to draw notes on a mockup or screenshot by dragging to create a box. However, creating an actual annotation space (a box) on a small device doesn't make much sense. The space is too small (and fingers too fat) for this to be a good interaction. That's why for annotation tests we actually modified the behavior of the test based on the device size — in other words, testers now tap to place a note on a specific location, not to draw a box around it.

That was among the few changes we made to finish out the new responsive tests in Verify. All in all, we were pleased to be able to keep our existing visuals and interactions even while porting it over to Foundation and implementing it to be responsive. Check out the new tests (on your desktop, tablet, or phone) and let us know what you think!

Last week, Bryan asked me why I always insisted on putting a space before and after an em dash. To me, it’s instinctual to put in the spaces. Why wouldn't I? But Bryan’s question got me to quickly look deeply as to why I did it.

Having worked at a newspaper, my editor insisted that writers always put a space between any em dash. "It looks cleaner that way," he told me. "Makes it easier to read." And it does. Let’s take a look at an example, using a sentence from Bryan’s recent article:

Today, we have expanded our efforts to include products, events and publishing — all to help our customers design great products faster.

Notice the space before and after the em dash. Here's how it would look without the spaces:

Today, we have expanded our efforts to include products, events and publishing—all to help our customers design great products faster.

Without the space, the words would be smashed together with the em dash. More than that, if everything was smooshed, the dramatic impact of the em dash would be undercut. But it's a stylistic choice, your mileage may vary depending what stylebook you pick up. We’ve even obliterated the Oxford comma, or serial comma, from that sentence (and from our stylebook). That’s because it’s more conversational, more informal without it.

However, these are the stylistic choices that designers and those who write their content must face themselves when considering how content falls on the page. Is a space important between em dashes? Does it make the page look cleaner? Oxford comma or not? What font should be used? How big? How small? Bold or not?

These are deadly important questions to ask considering that most Americans are on a daily 34 GB diet of content, a 100,000 words cross our eyes a day, and we need to be able to combat shorter attention spans.

We Control the Content

Another way to think about the writerly design of content is control of your page. Seems no detail is too small. Talking about this with Jackie, she mentioned how punctuation is extremely important to the design of a page:

The more we “lose control” as the world rapidly adopts multi-screen browsing habits, we have to perfect those things that we can control.

As the old saying goes, the devil is in the details. Those details can make the difference in enticing our audience to read our content. It's how we stand out. We can't lose control of our words, sentences and punctuation, especially those of us who are writing that content. We have to pick a style — spaces before an em dash, serial comma or not — and stick with it. In so many words, we control the content, even if it's something as small as an em dash.

Remember how yesterday we told you about refining your designs in-browser quickly? Well, that was only part of the story ... really, the tail end of the story of how we used Foundation to code up a prototype in the browser for our new ZURBword front page. Take a look at our old page:

As you can see, there wasn't much to look at. It was nothing more than a directory, a list of words with not much going on. We wanted something a bit more eye-catching that would encourage people to click around and check out our thoughts on some hearty design concepts. So around November last year, we started sketching out some ideas to take the site to the next level.

But did we want to take those ideas and put them into Photoshop? Or did we want to go straight to code, designing in the browser? A lot of designers debate whether they should design in browser or not.

However, the one big advantage to prototyping in the browser is that it's faster, trimming off several steps in the design process, especially if you already have an established visual style. Since we wanted to get the new ZURBword up as fast as possible, we decided to prototype it in the browser.

Getting It in the Browser

We started playing with a few ideas, trying to figure out what would actually work. Take a look at some of our early ideas below. Click on the images to see a larger image.

Here we lost a bit of focus on the content. There was too much line work going on and everything felt too structured and boxy. Overall, it felt too much like a beefed-up directory. So out these ideas went and it was back to the drawing board.

Playing around with the lines and images, however, we came up these next set of images. Take a look (click on the images to see a larger image):

The design on the left, however, felt too forced, an island of stuff in a sea of text. The one on the right broke things up, which was kinda awesome. But there was that darn line problem again. Everything felt trapped, contained too much. However, we played even more with the blocks of content seeing where it would take us.

Our exploration led us to the designs below. Click on the images to see a larger picture:

In the end, we did something like 10 iterations to get to our final design. But we weren't quite done yet.

Refining Our Design with the Inspector

As we said yesterday, we refined our designs by opening up the Chrome inspector. In less than five-minutes, a group of us, including myself, were able to quickly critique the design and suggest changes, which the inspector let us see instantaneously. We were able to change the background from white to gray and even add a drop shadow to the boxes.

We also reversed engineered Foundation to add a couple more columns on the side for wider screens. One other nifty touch was having the images rotate each time you land on the front page.

With those final changes in place, we were able to launch shortly after that. All in all, it took us a few weeks to get the new ZURBword up and running. And all thanks to in-browser prototyping.

Our days can be pretty busy at ZURB. Sometimes we don’t have time to stop everything and do a full-blown design critique. Sometimes we just want quick and dirty feedback. That’s where in-browser prototyping comes in handy, especially when we’ve got a design that’s nearly there but not quite there yet.

In-browser prototyping came in handy while we were putting the finishing touches on the rebooted ZURBword. The original site wasn’t up to snuff. So we put Arthur to work on a swank redesign. As he got closer to the final design, four of us huddled around Arthur and his computer, giving him a speedy design critique in about five minutes. To do it, we simply opened up the Chrome inspector to see some instantaneous changes. How we did it is something we wanted to share with you.

Getting Dirty with Chrome Inspector

The original white background of our nearly-complete page wasn’t quite working. So Bryan suggested using gray. That’s when we opened up the Chrome inspector, searching the left-hand DOM for the body element. Take a look (click on the image for a larger view):

We then went into the right-hand style box and started fiddling with the CSS, changing the color of the background. Click on the image below to see a larger picture of what we did:

Next we decided to add a drop shadow. So we moved in the DOM to the class we used for each of the containing boxes, to find the box-shadow in the style-box, double clicked on it, changing it to “0px 2px 5px rgba(0,0,0,0.15)” to add the shadow. Check out the larger image of what we did by clicking the image below:

Not An Excuse for Backseat Design

The changes only stick around as long as you don’t reload the page. Once you reload the page, the changes will vanish. So you’ll have to go into the actually CSS to make the changes permanent. Take for instance the box shadow, we used CSS3 to make it permanent on the actually code. (So that particular change might not show up on older browsers.)

In any case, in-browser design critiques aren’t an excuse for backseat designing. It’s meant to be really quick, really dirty so you can be scrappy and prototype your ideas instantaneously.

Today we released Foundation 2.2, a release which includes numerous bug fixes, refactorings, small additions, changes and just a general overall polish. You can check it out from Github or download it right from the site. This release is a good time to let you guys get a peek inside for a bit.

You see, Foundation 2.2 (or 2.2.1 if we need to mop up a few things) is the end of the line for Foundation 2. We're going to maintain that version of Foundation where it is, with the same high level of support and engagement you've come to expect as we begin work on the next big venture for Foundation: 3.0.

Why 3.0?

Something we've realized as we've been working on (and building with) Foundation is that, for us, providing tools to build things faster isn't enough. Don't get us wrong — we still intend for Foundation to be the fastest way to responsively prototype and build future-friendly sites. What we also intend it to be, however, is the fastest way to build better designed future-friendly sites.

For that, we need to significantly revise Foundation. We're going to change how we develop it (faster, easier to modify, easier to extend), change how it works (more cutting edge features with the same browser support), and change what it can do.

Get Involved!

For the better part of a year now we've been thrilled to see our efforts with Foundation reshaping how web sites are built, and we believe Foundation 3 will be no less revolutionary. The beautiful thing about Foundation is that you can follow along and help shape this release.

Hop over to Foundation on Github and watch the project evolve, checking out the changes and additions already tagged for 3.0. Suggest features, discuss changes, and even submit code you think would make Foundation even better. There's even a branch — 3.0 — that you can check out. Be warned, however, we'll be drastically modifying that branch in the next few weeks.

This is a very exciting time to be doing what we all do — changing how the Web is built, and building the Web itself. Your reaction to Foundation has been nothing short of astonishing for us, and we're looking forward to more incredible things, both for you and from you, in the coming weeks and months.

Over the years, there has been a jihad over whether to use spaces or tabs when writing code. It’s a holy war we fought ourselves at the ZURB offices, until we came up with a truce in 2009, saying spaces were for back-end development while tabs were for front-end development. But recently the war was reignited and we found ourselves fighting it out again over whether to use spaces or tabs.

The problem is that a lot of hackers are insanely passionate about the amount of screen columns that the code indents, as pointed out in this excellent blog post. Some prefer it to be two column while others like it to be four columns. Then there are the folks who prefer more complicated and context-dependent rules.

At ZURB, we had hackers on both sides of this battlefield — some for spaces and others for tabs. Spaces, however, slowly took over. Code kept getting written with spaces, and the backend folks mostly ignored the truce. However, the war heated up again when Tanya used tabs for some front-end code, which piqued the ire of our contractor, who fired back and reformated the code manually with spaces.

So we decided to put an end to the war once and for all, and make everything consistent all around with spaces, but not before delving deeper into the problem.

The Problem with Tabs

Because most arguments on the subject were esoteric, we asked our contractor why the tabs were problematic and why spaces are better.

Tabs wreak havoc, he told us, because they’re so wildly different on different editors. On some editors, tabs show up as two spaces, on others it shows up as four spaces and on a few editors tabs will actually show up as an entirely different character, he said. With a multitude of editors and hackers, these differences can cause some pretty whack alignments.

It gets even worse if you mix spaces and tabs while coding. Your code will only look good on your editor, but could look like crap on another editor. Here’s the example our contractor gave us:

Say we hacked this using two spaces for the div open and end tags, then used two tabs for the span tags, it could end up looking like this in an editor that interprets tabs as four spaces:

So, yeah, mixing tabs and spaces is bad, way bad. Don’t do it.

Spaces for the Win

As you can see, there’s no real benefit to using tabs over spaces because of the inconsistency of tabs. Around ZURB, spaces won because they're more consistent with the communities we work with and admire, such as Rails and SASS. However, whether you use spaces or tabs, the key is to be consistent so you don’t end up with some funky code that you’ll have to go back and reformat.