Viget Inspire

I recently visited a friend who was having some rooms painted. The walls of the living room looked like a patchwork quilt with daubs of various paint colors all over the wall. "I can't make up my mind," my friend said in response to the giant grin on my face.

My friend's dilemma is typical when starting a new project. Whether you're painting a room or designing a website, it can be a challenge to select the perfect color combination. Rather than getting into the process of color selection, I'm going to focus on some resources and techniques that can help make the job a little easier.

Continue reading "Picking the Perfect Palette"

This issue has been popping up all over the place lately. When hovering over elements with certain css3 transform properties set on the hover state, Chrome and Safari sporadically flash. Unless you're into causing seizures, this effect is probably not what you're going for.

To prevent the infamous black flash in Chrome and white flash in Safari, you need to set any element you plan on transforming in the future (like on :hover or with an added class) in 3d space from the start.

For Example:

.item {
  -webkit-transform: translateZ(0);
}

.item:hover {
  -webkit-transform: scale(1.5);
}

-webkit-transform: translate3d(0, 0, 0) will accomplish the same thing. The flash seems to occur when the browser switches to gpu accelerated rendering for an element. Thus, by giving the element a gpu accellerated property from the get-go, the browser does not have to switch in and out of rendering modes, and the flash is prevented.

There is a downside.

In Chrome, without this fix, if there is text inside of the element you are transforming, the text nicely re-renders when the transformation is done. With the translateZ(0) fix, the text is rasterized and stretched, causing things to get fuzzy. So say you scale some text up to 1.5 percent — you'll get something like this:

-webkit-transform: scale(1.5) WITH the fix.

-webkit-transform: scale(1.5) WITHOUT the fix.

As you can see in the second image, the text properly re-renders when the transform is complete (in Chrome), where as the second image with the translateZ fix does not. Ultimately, translateZ does seem to be the lesser of 2 evils for now. The good news is, that as of Chrome 17.0.963.26 dev, I'm not seeing the flashing issue at all. Hopefully that means it's been addressed, and that the public release and Safari will soon follow suit.

I’ve had a couple of designs recently where I have been able to play around with background-clip: text in combination with text-shadow and gradients, and I wanted to share my experience.

Before we get too far, background-clip: text is not supported in all browsers. I believe it is still only supported in Webkit browsers, so make sure you have sufficient fallbacks. The demos on this page will also only show up with all the fanciness in webkit, so I’ll wait for you to switch over.

Okay, ready?

Continue reading "Background-clip, Text-shadow, & Gradients; Oh My!"

For the last year or so, LESS has gained a lot of traction in the front-end development community, particularly among designers. LESS extends CSS with dynamic functionality and organizational features, which provide a lot of power and efficiency to designers and developers. However, it's not the only CSS pre-processor player out there. The other major one is Sass, which is very similar, and both are solid options to consider.

Many of the review articles out there do a good job of providing an in-depth look at syntax and general usage, but I'd like to take a different angle—highlight one difference that isn't written about all that much, and present a few features of LESS that have have proved very valuable on recent projects.

Continue reading "Some Lesser Known Features of LESS"

For the past two years we’ve hosted an event series we call Design Share at our Falls Church location. It’s proven to do everything and more that we set out to do. Namely:

• Connect with the local design community.
• Learn from each other by sharing behind-the-scenes looks at design and process.
• Provide a forum for people who are new to speaking to get experience in front of a low pressure audience.

Over the two year period we hosted 4 events in which 17 talented designers graciously shared their stories. Among them:

• Brian Talbot, National Geographic
• Jay Moore, AOL
• Eric Lohman, AKQA
• Rob Soulé, Viget
• Ari Kushimoto, CaviarFrenchFries
• Jason Garber, Ficly
• Elliott Muñoz, Edge Media
• Corey Greeneltch, Ironworks
• Ali Felski, Sunlight Foundation
• Dawn Sword, Serendipity Creative
• Owen Shifflett, Viget
• Stefan Poulos, Pappas Group
• Phil Gossier, Threespot
• Lee Costic, Lee Costic Design & Creative
• Gregg Glaviano, Grafik
• Katie O’Brien, Fleishman Hillard
• Sarah Sampsel, Washington Post

The format was simple. Share a short 5 to 15 minute presentation about a project and discuss further with a live audience. We archived many of these presentations at designshare.org.

Continue reading "Design Share: Dinner Party Edition"

Starting at Viget a little over a month ago inspired me to take stock of the best practices that I’d developed over the years. From whole workflows to the smallest code snippet, I decided it was time to upend everything that I thought was perfect and bomb–proof to see what still made sense. The result was that I uncovered a few IE6 cockroaches hiding in the corners as well as a few other things that I had lazily relied on, without question, for years.

What did I find?

I discovered one surprising, and embarrassing, theme: forward–compatibility can make us, as front–end developers, complacent.

Tried and true techniques that worked in IE6 will, not surprisingly, still work in IE9 (and every other modern browser) — and that’s not necessarily a good thing. As browser development marches on and we stop supporting older versions we also need to re–evaluate the techniques we had been using to support those browsers.

Dropping support shouldn’t just mean not firing it up in a virtual machine to see how things look and work. It gives us the opportunity to clear out the cruft and move forward.

For Example

Look at the good old Suckerfish dropdown menu technique. I’ve been thoughtlessly, but successfully, using JavaScript to aid dropdown navigation and other hover interactions for years. Why? Because IE6 didn’t recognize the :hover pseudo class on elements other than links and JavaScript intervention was necessary. When you take IE6 out of the equation (and we all should) things get much simpler and you can use pure CSS.

So why was I still using this antiquated technique? Because browsers happily run whatever error–free code we give them — even when it could be better, or more modern. Quite simply: it worked. It has always worked and always will work and no browser is ever going to complain about it. Talk about a smooth–running bomber technique — and a perfect example of something that had to go.

We’ve all done it

By now you’re thinking “duh, Jeremy, I haven’t used JavaScript in my dropdowns for years”. Good for you! But I bet you’ve got something else hiding in the attic. Care to share one?

Moving Forward

So where’s the impetus to change when there’s virtually no friction? Refactoring code and removing unnecessary parts makes it simpler, smaller, more easily maintainable and less error prone. I think we can all agree that those are good things.

But there’s something more — it’s about being actively engaged in our craft. The speed of progress can cause us to hide behind best practices like a shelter from the storm of blog posts touting the newest thing. The key is finding a balance between stability and progression — or maybe you just need to upend everything once in a while.

Think about your favorite code snippet. If you had to rebuild it today, wouldn’t it be better? What’s your technique for keeping things current while still maintaining standards that speed up your day–to–day work?

It’s an exciting time for CSS. On top of the advances being made both in what to write (CSS3) and what to write with (SASS+Compass, Less), CSS is enjoying a spate of serious discussion over how it should be written.

This might come as a suprise to some (and did to me). After all, CSS seems pretty straightforward — without many of the complexities of programming, CSS has long been seen as something you just write. After all, it’s not particularly hard to write good CSS and markup; so long as your definition of “good” means “looks right, seems consistent, has semantic value”, you’ve generally gotten a pass.

The question recently posed is: is this definition of good, originating from the dark ages of table layouts, good enough to deal with the problems CSS encounters in 2011?

The answer might depend on a few things: first, whether you observe such problems, and second, whether you see them as sufficiently difficult to work with. As I see them:

Continue reading "CSS Strategy Square-off"