refresherate.com

Refactoring is a concept that is often used in the context of programming. In fact, it’s one of the cornerstones of Test-Driven Development (TDD) in Ruby on Rails. Oddly, I rarely see refactoring discussed in the context of writing CSS and XHTML. Whether you write Ruby, PHP, Perl or CSS and HTML, refactoring your code should be a part of your coding workflow.

So what is refactoring? It’s basically cleaning up your code, making it more efficient and easier to maintain. When writing prose, you bang out a first draft to get your ideas down on paper. It’s a bunch of crap often. Then you revisit your mess and make it beautiful and worthy of submitting to your local town paper.

Coding is no different. When writing XHTML and CSS I am often trying out things, adding extra divs and spans, and creating a mess of CSS and XHTML. It’s called the process. It’s messy. When I finally get to the look I wanted to achieve, I take a quick break and bask in the glory of having everything aligning and looking the way I had envisioned it to look. But I am not done yet. Far from it. I must refactor my code.

Refactoring code removes duplication, aids in readability and maintenance of the code in the future. The goal here is to make things simpler, while continuing to achieve the layout I have designed. If you refactor and suddenly something doesn’t look right, that is not refactoring, that is breaking something. You want to refactor in small steps and test your code in the browser to ensure things are still working as intended. You should be using some form of source control management (SCM) like Git and regularly checking your code changes in. This way if you botch something, you can always pull a working version out of your SCM.

Now you might be thinking to yourself, I write semantic markup, isn’t that refactoring? No, that’s called doing your job as a standards aware designer. You should always strive to create meaningful markup. That’s the name of the game. Refactoring is revisiting your code and identifying areas where your code can be improved, streamlined and made simpler. In six months or a year, when you revisit this code you’ll spend less time trying to remember how this code works because you took the time to make it simpler and easier to maintain.

Refactoring is a huge topic and I plan on addressing it using several examples in a series of posts on the topic. We are going to take some baby steps here. For now I will leave you with a simple refactoring of CSS.

I ended up writing this CSS code in a site I was working on today:

Do you notice something in this code? There is a huge amount of duplication here.  The height and the padding-top attributes are the same for each of these classes. This duplication violates the DRY principle: Don’t Repeat Yourself. Duplication is a very bad thing. If we want to change the height, we have to change it in four places. This is not ideal. A better approach would be to refactor this CSS and remove the duplication and place it into a group of parent classes:

So here I  have refactored out the duplication and placed it in a group of parent classes. Now if I want to change the height of padding of these elements, I just need to deal with making the change in one place. The readability has been improved along with the maintainability. And I have saved a a few lines of CSS. While not a huge amount in the small example, the LOC saving in a large CSS file can measure in the kilobytes!

Thats it for now. If there is one takeaway in this lesson, it is look for and eliminate duplication whenever possible. Stay tuned for more examples of CSS & XHTML refactoring.

Browsers are continuing to innovate and bring support for new methods which promise to make designer’s lives easier and more flexible. At An Event Apart in Boston this week was a call for designers to embrace the future of web design and start leveraging these emerging browser technologies. It’s time to get over the fact that web sites are going to look different in every browser. That’s the nature of the medium.

One exciting emerging technology is @font-face, a CSS specification which gives web designers the ability to add embedded fonts to the font-stack for use in on a web site. Web design has long suffered from an impoverished offering of web-safe fonts. Nonetheless, we have made a beautiful web with what we have been given, all the while turning a green eye towards print designers and their limitless selection of tidy fonts. The prospect of embedding fonts is exciting no doubt. Designers have wanted this flexibility for years as evidenced by such hacks as sIFR. sIFR works, but it’s imperfect. An interim hack at best until we have better techniques.

The two main road-blocks to using @font-face has been browser support and font licensing. Safari has supported @font-face since version 3.1, IE since version 4, albeit using a proprietary method (big fucking surprise), and Firefox will support @font-face in version 3.5 (released today). So we are getting to a point where browser support is no longer an obstacle. So lets check that item from our lists.

Now there is still the problem of font licensing. Sure, there are a lot of free poorly crafted fonts which have licensing that extend to the web. There might even be some reasonably nice free fonts which we can use. But all the big font foundries have refused to extend licensing to the web, and with good reason. There just hasn’t been a reliable way to embed fonts into a page in a manner which prevents the fonts from being downloaded. Web sites that use @font-face are basically making the fonts they embed available for public download. Not a good deal for the font foundries.

But that is about to change with the advent of Typekit an up and coming service set to launch this summer. Typekit allows web site designers to license fonts from the font foundries in a secure manner which protects the foundries fonts from being publicly downloadable. It’s very exciting. Is it perfect? I don’t think so. I have yet to see the service as it hasn’t launched. But it sounds like the service will somehow tie your web site to the Typekit service. Coupling sites can lead to problems. What will happen if Typekit’s servers go down. Nonetheless, this is progress. A first step. Opening the dialog up with the font foundries is huge. This is an industry that has feared the web for a long time. To bring them to the negotiating table is a momentous thing and the web will benefit from it enormously. I am certain more innovation will be made and we can thank Typekit for getting the ball rolling.

Resources:

• Typekit (sign-up to be notified when the service goes live).
• Typekit Blog (while you are waiting for Typekit read about their progress and get involved).

It’s always a good idea to compress JavaScript and CSS files in order to have them load faster.  However, it’s a compressed file is nearly impossible to edit if you need to make changes down the road. Enter Minify. Minify is a PHP5 app that can combine multiple CSS or Javascript files, compress their contents (i.e. removal of unnecessary whitespace/comments), and serve the results with HTTP encoding (gzip/deflate) and headers that allow optimal client-side caching. It’s a pretty sweet deal.

Here’s a great tutorial on how to create a top navigation similar to vimeo. It appears to be a bullet-proof design allowing for expandable navigation elements thanks to the way the corners are implemented. Check it out.