What you can learn

By far the largest resource available on Let’s Make the Web Faster is the collection of articles available. The articles are put together quite well, involving a good blend of video and supporting imagery. You’ll be able to quickly learn the background behind some of the jargon used in document optimization.

Articles aren’t limited to front end development, because there’s more to writing markup and style if you’re a Web designer. Google takes the time to discuss other relevant areas such as the optimization of Web graphics for faster download times without losing quality. There are also articles on optimizing your JavaScript and even some PHP performance tips. One of the headlines that first caught my attention was UI Messaging and Perceived Latency — what a great topic. Google also includes a number of links to various Tech Talks @ Google, which are always a good watch.

Let’s Make the Web Faster launched as a very information-rich resource, and I imagine Google will be adding new articles fairly consistently from here on out. What’s great is that Google has done its part in retaining the community value of Web developers by devoting a section of Let’s Make the Web Faster to the community, opening doors for your input.

As with everything, be wary

Just because you read it on the Internet, the information you got may not be bulletproof, even if Google wrote it. Articles attempting to Debunk Google’s Internet Optimization Tips are beginning to crop up, and I think it’s great. Google suggests a number of techniques, actively put in practice on many Google products, that I will personally never employ just because it skirts around a rule or two. Saving a few bytes by writing sloppy code just isn’t something I’m interested in doing.

Like every Web designer, I’ve worked in PHP. I tend to really like PHP, but I don’t know PHP on the intimate level that programmers know PHP. I’m still learning about how the language itself actually works. I’m specifically interested in what PHP does differently than other languages which causes it to be huffed and puffed upon by so many.

It’s very interesting to read that some of the PHP optimizations suggested by Google may not be entirely accurate. I always enjoy reading technical pieces written by programmers who will always know more than me about programming. The existence of such a thread shows the nature of the PHP community, and it’s good to see that even Google might not know everything after all.

The important thing to keep in mind when reading Let’s Make the Web Faster, as with reading every article on the topic of Web development, is to take everything with a grain of salt, and to not follow the advice blindly.

Page Speed for Firebug

Everyone knows about Firebug. It’s arguable the most widespread, actively used tool by the majority of developers and designers, and for good reason. The tool changed the way many people approach front end development, and it was a true game changer.

Some time ago, Yahoo! released an add-on for Firebug called YSlow. The tool aimed to help developers analyze documents and suggest optimizations not only for speed, but rules for optimization. YSlow proved to be very helpful for many people, and I know I learned a thing or two about some of the techniques I had been using for quite some time.

As part of Google’s initiative, they have released Page Speed, also a Firebug add-on aimed at page performance analysis. After installing the Page Speed add-on, you’ll notice a new tab within Firebug:

As with YSlow, you need to invoke the analysis by clicking a button quickly after navigating to the document you’d like to test. After completion, you’re provided with a very detailed report containing a breakdown of the criteria against which your document was run:

Additionally, Page Speed takes another step forward in offering to apply a number of optimizations to your document immediately. For instance, if deemed necessary, Page Speed will go ahead and minimize your JavaScript on the fly, as the browser downloads the JavaScript, having an optimized version ready at any time:

The last feature within Page Speed I’d like to tout is the CSS analysis. Beyond suggesting the combination of CSS files to reduce the number of HTTP requests, Page Speed will examine your style sheet on a per-line basis, letting you know what could be written better:

Page Speed will separate your ‘very inefficient’ and ‘inefficient’ rules and let you know what makes each less than ideal.

As with YSlow, Page Speed has links throughout the panel directing you to the information backing up the suggestion, found on Google’s Let’s Make the Web Faster. I would suggest that everyone have Page Speed at the ready during a testing phase of a Web project. It will make sure your documents are top notch concerning performance, and you’ll become a better developer because of it.

There is an abundance of information available if you’d like to read a bit more before installing Page Speed. Even if you’re not a Firefox user, I absolutely suggest keeping it on hand not only for render tests, but optimization tests using Page Speed as well.

Overall impression

There is a lot to learn as far as Web page optimization goes. As new technology appears, you’ll have to learn even more, but it’s an important aspect of Web design and a valuable part of the medium. It’s important for you as a professional to know how to produce work of the highest caliber, and optimizations can do a great deal to make your work feel that much more polished. Google’s “Let’s Make the Web Faster” is a great platform that should help spread the word very quickly to a large audience.

I hope to see Google continue developing content for the recent project, and I hope to see a decent community response, especially debunking any poor advice Google may be giving by offering detailed responses. While certain practices may achieve the most desirable result, it will be up to the community to ensure that the actions aren’t welcoming detrimental side effects causing more problems than before.

Advertise here with BSA

That said, depending on your billing structure, you’ll be able to optimize your workflow in such a way that not only reduces your stress level, but will make your clients happy to boot. I mention a dependence on your billing structure simply because sometimes getting a project done well under a time-based budget can result in trouble for you financially. The important thing to realize, however, is that with newfound extra time comes extra polish. If you come in a few hours under budget, you now have the time to try that element you were toying with in design. Does it work now? How about the leading in that area? Would it look better if it were bumped up, just a bit?

Reducing the time you spend on front end development can lead to more experimentation and a better end product should you have extra time to play with late in a project. Personally, I like to keep front end development estimates to a minimum, allowing the budget to focus on design. I work with a team of designers, so the better we plan from the start, the better a project will go.

Have a plan, start with a static file

By far the most effective way to cut down on front end development time is to be involved in the design process. You don’t even have to be the designer, but you should periodically review any design for a basic feasibility assessment. That’s not to say that you should be prototyping designs to make sure something is going to work, but you should be able to process a design to a level that will let you be comfortable with it.

As you examine a design, try to abstract your brain from admiring the aesthetics of the design. Try to visualize how you will approach the front end for this document. Take a look at a comp for another page, can you determine how much markup and style you’ll be able to reuse from the first page to this one? Are there any modifications that should be made to the design to establish some consistency on a more technical level? Take a second look at the design, take a third look. Has someone added a gradient or texture that physically can’t translate to the Web?

Once you’ve signed off on approval for a design and it comes time to begin work, I can’t emphasize enough how much it will help you to start with a static HTML document. Stay away from your server side technology, no matter what it is, and instead use a static file that takes advantage of any dynamic resources you’ve set up.

For example, at my company we’ve established a site framework that we use to begin each project. In this site framework is your usual array of template-supported, server-side powered files that tie in directly with our CMS, and the like. Alongside this set of files are two static files: home.html and secondary.html. These are the first two files I’ll open and work with on a project.

The files are prepped in such a way that the path to the CSS directory is hard coded, removing the need to copy and paste once our original documents have been written. I’ll work my way through a secondary page, then the home page, and once that’s done, I’ll integrate.

Write your markup first, all of it

Nearly two years ago, I wrote about my development and design process. Much of my strategy remains the same to this day, specifically the first steps I take. The initial markup process ties in heavily with the original review of a site design. From the first time I open a PSD or PNG my mind begins working, breaking down the design into markup and markup alone.

I’ll break apart the design into sections, until I’ve found myself at the lowest common denominator, whether it be an h3 or an li. Once I’ve got a general idea of the overall structure, I’ll write it. All of it, from #header to #footer. I’ll switch to and from Fireworks (or Photoshop) and my editor, making sure all of my elements are in place.

Writing the initial markup for a document doesn’t take very long, an hour if you take your time. There really isn’t that much to it, especially if you’ve had a look at the design as it was being put together. You already know what to expect, and you can hit the ground running.

The important thing to keep in mind at this step is optimization. Don’t move on to CSS until every bit of markup is in place to support the design. Sure, you’re probably going to have to add an element or two as you continue development, but getting the initial structure entirely in place will be super helpful when it comes to the style layer.

Use a reset stylesheet

I can’t stress enough how helpful a reset stylesheet is when it comes to optimizing your front end development. It doesn’t have to be Eric Meyer’s reset stylesheet, but working from a consistent base is extremely helpful when it comes to building out your CSS, even more-so when it comes to The Browser Gauntlet.

Write CSS in blocks

I can remember my first few weeks with CSS; I’ve never been so excited to refresh a browser, and I never will be again. With each refresh came a new and exciting change that I was struggling to understand. Learning about CSS was very exciting for me, but it forced me to implement designs slower than ever. As with everything, the more you do, the better you get. As your skill with CSS grows, force restraint on yourself when you think you need to refresh the browser.

Chances are, that property:value; you just set is going to work out just fine. Move on to the next, and the next. Finish setting all the properties you want for that selector and then switch over to refresh. Once you’ve become comfortable with that, style an entire div before refreshing. Once you’ve become comfortable with that, structure your entire document before refreshing, and the move on to styling each div you just positioned.

The more CSS you can write in a single thought, the better and faster you’ll be. The important thing to keep in mind, though, is not to write too much at once. As you’re forcing yourself not to refresh, you may make a significant mistake that wreaks havoc on a few dozen lines of later CSS. Push yourself, but don’t push yourself too far too fast.

Save JavaScript until last

Exciting as it may be to implement, make sure you’re postponing all JavaScript development until last. Integrating JavaScript too early is going to destroy the integrity of both your markup and style, and will cause more trouble than it’s worth.

Instead, take the time to develop the markup and style for any states you may be integrating with JavaScript, and make sure they’re ready to be toggled (or otherwise) via JavaScript. Abstracting markup and style from JavaScript can help you to focus and optimize as you put together a design.

Take advantage of helpful tools

My last tip is something I depend very heavily on; finding the right tools for the job. If there are any applications under consistent development and refinement, it’s Web development applications and tools. Even browser makers are now giving us gold platters with which to work through built in developer tools.

First, find yourself a great text editor. Who cares what everyone else is using, find something that you enjoy working with, and most important: something stable that saves you time. I can definitively say that TextMate (Windows users: e text editor) has had significant impact on my development time.

There are plenty of fancy tools out there, but I can’t stress enough the importance of your editor.

Along with your editor, another integral part of your workflow is your browser of choice. Your browser should support your efforts, providing the tools you need to get the job done. Toolsets for browsers have been talked to death, but a favorite tool of mine has never received much press, and I’d like to heavily suggest your adoption of it.

ReCSS is a bookmarklet that comes from dojo and it’s something I use on a very consistent basis with every project. The sole purpose of the bookmarklet is to force a reload of CSS used on the current document. This helps you to avoid reloading the entire page (including server processing and other latency) and instead request only the latest stylesheets. It’s such a simple idea, but I’ll use the bookmarklet at least a few dozen times per-project to ensure that I’m not dealing with any caching issues.

Let’s have it

Do everyone a favor and post your favorite time saving front end development tip or trick.

Advertise here with BSA

The way you write your CSS today depends heavily on what you were initially taught (self or otherwise) in conjunction with other things such as what you’ve read that counteracts your teachings, as well as the level of desire to improve your craft. I like finding out the lessons learned behind your reasons (or lack thereof) for writing CSS the way you do.

I really enjoy writing about CSS, and if you’re a fairly recent subscriber, here’s a quick breakdown of my tips, tricks, and suggestions from the past:

Write Better CSS

One of the earliest articles I had written for Monday By Noon, but I still practice much of what was written over three years ago.

Improving Your Process: CSS Techniques Part 1

In the first part of the Techniques series, I mentioned a few ways that I tried to be more organized with my CSS writing, especially when working with a team. I have made some revisions since the publication of that article, specifically in dealing with browser defaults. Apart from that, I still stand by the advice offered in that piece.

Improving Your Process: CSS Techniques Part 2

In this article I made public my switch to using a reset stylesheet. I also tried to put into words some of the thought process behind my front end development process. You won’t find many code samples in that article.

CSS Organization Methods and Writing Style

This article was all about writing style. Style as far as comment blocks, overall stylesheet organization, right down to single line versus multiline. I touched on the idea of using flags as a hook for searching to quickly find various sections of your stylesheet, but that didn’t catch on with me.

With that reviewed, I’ve got a few other things I’d like to share as far as my CSS writing style is concerned.

It’s about patterns

One of the best habits I’ve found for myself is the desire to find patterns in designs. Patterns go a long way in design, and every good design inherits a certain level of pattern. Whether it be in organization, texture, or otherwise, a pattern provides consistency, and you’ll see patterns everywhere on the Web.

It will be in your absolute best interest to discover these patterns prior to writing a single line of markup or style. You want to use patterns to your benefit. Not only will finding patterns reduce your workload, it will make maintenance that much easier.

Jeff Croft recently posted an insightful article on finding patterns in CSS, but instead compared it to applying OOP concepts to CSS. I’m a big fan of Jeff, and much of my fandom comes from a similarity not only in workflow, but also opinion and thought process when it comes to Web design. In that article, Jeff puts into words something I’ve tried to verbalize in the past, and I’m thrilled to have it as a reference now.

I can see how using OOP methods in your CSS can be an eye-opening discovery, but it’s very important that you don’t become overzealous with it. As with many aspects of Web design, there is a fine line to walk when it comes to finding a happy medium with something like this. You’ll need to take a step back and really think about your implementation before taking action, else you’ll find yourself fighting an uphill battle when it comes to troubleshooting and maintenance. Using too many classes in a widespread way is going to cause trouble when you need to make a sitewide change and need to edit nearly every file on the site because you used a combination of classes in too many places.

Before I begin writing a line of markup, I take enough time to look at every comp for a website. I’ll look to see which elements, both structural and stylistic, have a repetitious property to them. I’ll keep these repetitions in mind as I write my initial markup, and then again when I’m later starting to write my CSS, and use the patterns to my advantage. Experience will help you better recognize and use patterns as you design and build more websites, but it will be a great skill to focus on throughout your career.

It’s also about structure

One of my biggest peeves when maintaining CSS is poor stylesheet structure. That is to say, when a production stylesheet has been in place for a decent amount of time, and the website has undergone some revisions, the edits were not properly put in place. Instead, declarations are sometimes simply appended to the end of the file to ensure their application, instead of finding the proper place in the file in which to make a change. I can recognize the desire to do such a thing, especially if you’re doing maintenance yourself, and the original file structure is so unkempt it would take hours to sift and organize it yourself. While the fault lies with the original author, it’s something that should be entirely avoided from the start.

I don’t mean to say that the way I write my CSS is a superior way to do so, my point is that you need to have some structure to your stylesheets. The technique I use for structuring my stylesheets is roughly the following:

1. Global styles such as ‘main’ copy properties (size, color, font) at the top
2. Global structure definition (main (secondary) page structure)
3. Header styles
4. Content area styles
5. Sidebar styles
6. Footer styles
7. Per-page specific styles

My basic reasoning is to work top down as far as specificity is concerned. I’ll work from the most global properties down to the most detailed as I work through a stylesheet. I try to keep things organized with how I think in a way. I’ll start with the main structure of the document, and then continue to style the header, content area, sidebar, and footer, respectively.

Once the more generic, consistent styles are taken care of, I’ll set up sections of the stylesheet specifically for one-off pages in the site should the design require it. Proper attention is given to these groups of styles via comments outlining which page is associated with a set of selectors.

Working in such a way will help you abstract which edits will affect the site in its entirety as opposed to the single instance you’re trying to modify. When working on a site you didn’t originally style, it’s very easy to make an edit that may in fact destroy a significant portion of the site you’re not even aware of.

Do you consitently keep your CSS in check?

Is it strange that I still put this much emphasis on the quality of my stylesheets? Are you at all interested in how other people write CSS or do you prefer to work in the way you’re comfortable? What techniques do you use when organizing your stylesheets from a more global perspective, as opposed to writing comments here and there for reference?

Advertise here with BSA

The building process

Over the past couple years I’ve wavered back and forth between building websites in Firefox and Safari. With the release of Safari 4 beta, I’m 95% sure I’ll be sticking with Safari this year (the Web Inspector alone is stunning). The main point I’d like to get across is that you begin work on every website using a modern, standards-respecting browser.

Using a well built browser will help keep your markup and style lean and clean. Starting out with a substandard browser will bloat everything from the start; not something you’re looking to do. After your initial build, you can then take your work through The Browser Gauntlet.

It’s a familiar feeling for any Web designer — you’ve completed the first series of pages, you feel great and go get a cup of coffee. The next time you sit down, it hits you: time to test. To this day I still get a few butterflies as I come to that very realization.

My Browser Gauntlet

My primary workstation is a Mac, so I’ll begin testing using browsers native to OS X. After building the site in Safari I’ll quickly test in Firefox. It’s been a long time since any discrepancies have appeared during this first test, so it’s more of a quick sanity check and move on. From there I’ll test in the latest stable, public release builds of Opera and Camino. I’ll also check things out in the latest WebKit Nightly to future-proof a little bit.

Although I test in five browsers at this stage, it usually takes only a few minutes since each browser is extremely capable as far as standards are concerned.

The next thing I’ll do is boot up Windows XP via VMware Fusion. I’m a huge fan of Fusion, but using a virtual machine (in OS X or otherwise) is a serious timesaver.

I’ll begin testing in Windows with standards capable browsers. First I’ll test in the latest public release of Firefox (3.0.7 at the time of this writing). I’m also still testing in the latest version of Firefox 2 (2.0.0.16) as I’ve found some discrepancies when working with Flash between Firefox 2 and Firefox 3. I’ll also test in the most recent versions of Opera, Safari, and Chrome. Again, this testing usually takes a few minutes at most.

Next I’ll test in Internet Explorer. I’ve tried a mix of Snapshots to test each version of IE, but found that process to be a bit slow for my tastes. I’ve had great luck with IETester, a free Web browser that lets you easily switch between Internet Explorer rendering engines. As of this writing, IETester is at version 0.3 and includes engines from IE8 RC1, IE7, IE6, and IE5.5 on both Vista and XP.

Some designers I’ve talked to feel IETester is a bit buggy for their taste, but I’ve found a trick that works for me and has absolutely no technical backing. If the first tab you open is of the default browser on your system, switching between various rendering engines is quite stable.

Using IETester, I will first test in Internet Explorer 7, and correct inconsistencies using conditional comments. Once things are stable in IE7, I’ll move to IE6, which is the longest stage of The Browser Gauntlet. Again using conditional comments, I’ll make my way through the shortcomings of IE6, gracefully degrading where applicable. I don’t make a big deal about it, just make things tolerable and move right along. Last, I’ll quickly look at the site in IE8 (latest release) and tidy up there as well where I can. I no longer test designs in Internet Explorer 5.5 as our metrics don’t call for that attention to be provided.

The final steps of my Browser Gauntlet reside in Ubuntu. Ubuntu is my Linux distribution of choice, and I always keep a stock installation available in Fusion not only for testing purposes but also to play around with from time to time. I feel it’s important to test in a Linux environment not because a significant number of people are using Linux, but because the operating system gives us some variables we may not have otherwise expected. The most obvious differences are with type rendering in the browser, so I make sure to keep only the default font installed that come with Ubuntu. This helps me validate included font stacks and make sure nothing breaks for Linux users.

Once I’ve booted into Ubuntu, I’ll first check renderings in Firefox. From there I’ll check things out in Opera, Epiphany, and Konqueror. These browsers often use the latest releases of either Gecko or WebKit so it’s rare that any significant trouble pops up. The most significant thing I’ll keep an eye out for at this stage is type inconsistency.

Once testing in Linux is complete, I’m quite comfortable moving on to the later stages of development (integration with a CMS, adding behavioral JavaScript, integrating Flash elements, etc.). I’ll repeat this process before showing the client anything, just to make sure the design is properly reflected after the bulk of the work has been done.

Testing in mobile browsers

The mobile space will continue to advance, and when a client requests a mobile version of their website, there is an additional step to browser testing that takes place. While I don’t have a wide array of mobile devices on which to test, I’ll do what I can with the tools I do have. Primary testing takes place in the iPhone simulator, as iPhone optimized sites are primarily requested at this time. The iPhone simulator is available in the iPhone SDK and allows really quick and easy testing of iPhone-optimized designs. Blackberry optimized sites are also requested from time to time, and although much less streamlined, there are a series of device simulators available. The simulators are Windows-only, so I’ll do my Blackberry testing using those tools made available. Another popular platform to test with is Opera Mini. Many handhelds use Opera Mini, and the Opera team offers a simulator (demo) for that as well.

Unfortunately, not many of my clients have requested mobile optimized sites, but I will be integrating that testing pattern into my process as more websites come through the door.

Effectively testing for the mobile space is not as easy as the desktop, but more tools are becoming available, and there is always the device itself on which to test. Unfortunately quite a bit comes down to the client budget and how much has been allocated for the mobile space. We’ll be seeing more mobile-optimized clients over the coming years, so it will definitely be in your best interest to learn about the available tools and become familiar with them.

Your turn

Browser testing is a bit of a pain for Web designers, but it’s also a responsibility. One thing I’ve noticed as I continue refining my skill, is that browser testing takes up less time with each website I build. With each website, you’ll more than likely pick up something new. With each piece of knowledge, you’re preparing yourself for upcoming projects. You’ll have in the back of your head the knowledge that building this layout is going to cause the same headache as the last one, and you’ll be able to take a more aggressive approach to solving the issue before it’s even a problem. Don’t look at browser testing as a hassle, instead think of it as the finishing touches on the best work you can do.

Is your Browser Gauntlet similar to mine? Are you testing in a browser that I’ve overlooked? Do you have any tricks up your sleeve to make browser testing less painful?

Advertise here with BSA

Browser usage; who cares?

I follow usage statistics. I follow usage stats not only for my personal sites as well as prospective client sites (when possible), I also follow usage stats for existing client sites for which we collect analytics, as well as more broad metrics from services such as Market Share. As with all statistics, it is terribly important that you search for and validate as much data as possible before coming to any sort of conclusion. Browser usage metrics are values designed to be taken with a (decently sized) grain of salt. Of course user agent strings can be easily forged, and data sets can be easily skewed. The important thing to remember is: browser usage should still be of great importance to you as a modern Web designer.

I’d like to be completely clear in saying that usage stats should be important to you as a professional designer, but the numbers should not have adverse affect on your design. Modern Web design has taught us that a well balanced combination of progressive enhancement & graceful degradation can simply work wonders.

When it comes to tackling IE6, we can guarantee one another that there won’t be too much progressive enhancement going on. Instead, we’ll be putting graceful degradation at the forefront of our minds; thinking of straightforward ways in which to make the user experience equally valuable. My professional opinion is that IE6 should not be disregarded.

I do not propose that any exorbitant amount of time, effort, or money be put behind any sort of IE6 movement. I do feel that the choice to not support IE6 should be backed by useful data about your target audience, and at the very least a minimal version of your document be available for use.

IE6 and me

Every Web designer I’ve spoken with offers a familiar shudder at the mere mention of IE6, which usually turns into a moment of comradery between the two of us. It’s no secret that IE6 provides a sub-par browsing experience, that horse has been beaten to death too many times over (along with its entire family of IE6 horses) for my liking; and I’m not the only one. There are many designers who have taken the leap to complete lack of support. There are others who continue to describe each ache and pain provided by IE6 on a fairly consistent basis. Me, I’ve taken a more passive approach in accepting IE6 for what it is, and coming up with my own plan of action.

In my personal opinion, it’s going to take a worldwide colossal event to remove IE6 from our lives. Take for instance, the following graphs. These graphs represent browser usage on Monday By Noon, as well as usage statistics for a client website with a much more technologically diverse audience.

Monday By Noon is aimed at a very specific audience; Web designers and developers. To anyone who reads, questioning the market share IE6 possesses would seem to be a silly question. You would think it would be a safe assumption that IE6 market share for that traffic wouldn’t amount to much at all. I was surprised to find out that recent metrics show IE6 holding strong at 5% of my viewers. I cannot think of a decent explanation for that. Believe me, I’ve tried.

A more realistic (and therefore more useful) graph to take a look at is that of the general traffic website. Internet Explorer six is responsible for about 22% of traffic on that website. That percentage falls in line with what I’ve found to be (mostly) true with general traffic on the Web. At the time of this writing, about 25% of traffic on the Web is carried via Internet Explorer 6. To say that’s insignificant is simply untrue.

I feel that I should be completely explicit in saying that if your target audience simply does not coincide with numbers like these, and you’ve made the educated choice not to support IE6, I can find agreement in that. The important thing is that your decision was educated, not made by following the latest fad. Internet Explorer 6, in and of itself, still holds great importance to any Web designer.

That said, I’d like to share the details of my IE6 strategy.

Strategizing your IE6 process

Like all good outcomes, my accommodating IE6 starts by coming up with a plan. When reviewing design comps, I’ll start by visualizing the overall structure of the document and how the CSS will be applied to that. Before making the first cut, however, I will go over in my head what will likely give me trouble when working with IE6. Yes, IE6 has earned those five minutes of my time, and it will pay off ten times over when it comes to testing.

Throughout my analysis of the comp, I’ll decide whether various design features will be “worth it” to implement. The “worth it” scale considers both the target audience as well as the design purpose. If the target audience is minimal, and the design purpose is subtle, I will plan to gracefully degrade that feature. An IE6 user isn’t going to notice that there isn’t a drop shadow there.

I’ve honed my process so that the only hurdles left for IE6 usually have to deal with PNGs. Past experience will tell me whether a PNG will work within a particular application. If obtaining alpha transparency simply isn’t “worth it”, I’ll go ahead and use a gif. If the transparency offered by a gif will just look sloppy, I’ll figure out a way to use a jpg.

I’ve found that it isn’t worth my time to rip my hair out to make sure a design element is carbon copied from the design comp, if a gracefully degraded version will work out just fine. After all, we’re catering to a small(er) group of users employing a long expired browser.

Of course, tackling alpha transparency is hardly a well kept secret. By far the most frustrating thing to deal with when testing in IE6 is layout.

How to avoid layout headaches

Mastering the float is one of the biggest learning curve for modern Web designers. It’s very frustrating to finally grasp what’s going on only to realize the need to spend just as much time ‘making it work’ in IE6. I’ve seen it happen many times, and it will happen many more. Lucky for me, I’ve got two methods which have saved me many headaches when it comes to testing.

Respect the Box Model

As I’ve said before, something I always keep in mind is to avoid box model inconsistencies. Find a way to prevent setting a margin/padding along with a width/height. Stopping yourself there will work wonders.

Margin and padding bugs with lists

Even if you stop yourself from falling into Box Model traps, IE6 has a way of completely destroying your carefully styled list items. If it doesn’t have one, give the parent list element a width, and set width:100%; float:left; to each child <li>

Control your clears

This tip heavily depends on your clearing method of choice. I’ll explicitly state that my experience has lead me to know and trust the overflow:hidden; method of clearing. If you’re not familiar, adding overflow:hidden; to a parent element containing floating children will force that parent element to encapsulate its children, effectively clearing itself. This method has worked well for me for years.

Working with this method of clearing and IE6 requires you to have a small trick up your sleeve, though. Simply adding overflow:hidden; to your parent element won’t work in IE6 if the element hasn’t triggered hasLayout. Luckily this is (usually) a very easy fix. To force that parent element to clear itself in IE6, simply open your IE6-specific stylesheet and add height:1%;.

Adding height:1%; will trigger hasLayout and your element will now clear itself, allowing you to move on quickly. Of course this solution isn’t always perfect. This method requires you to plan ahead, setting up parents and children to cooperate. For me, this clearing method has allowed me to write lean, semantic markup, with a minimal IE6 contingency plan.

It’s very important to keep in mind, however, that this clearing method can backfire and turn on itself. As your designs become increasingly involved, you’ll develop a tendency to toss height:1%; on everything. Resist that urge. In order for this to work, you’ll need to only add height:1%; on each of the parent-most elements you’re trying to clear. That’s not to say you can’t use this method more than once per design (you absolutely can). You just don’t want to end up overlapping your height declarations, possibly resulting in more hidden content than you started with.

Keeping those three tips in mind should give you quite an arsenal when it comes to IE6. Keep in mind that all you need to do is gracefully degrade. The more websites you design, the better you’ll become in dealing with IE6 during testing. Before you know it, your IE6 stylesheets will only be a few lines long, and you’ll be able to focus on the best parts of Web design, not the worst.

Do you have any IE6 rules you live by? What tips/tricks/techniques have you come up with throughout your career?

Additional Reading

• Stop being a dick, support IE6

Advertise here with BSA

For me personally, it’s disastrous when I’ve found myself burnt out on anything related to work. I suddenly find myself consciously avoiding the activity I enjoy most. While being burned out on a job you don’t enjoy in the first place may be quite a bit more common, with (most of us) working on the Web, we’re often doing it by choice, it’s what we love to do.

Recognizing you’re burnt out

It’s sometimes difficult to realize you’re burnt out as opposed to day-to-day stress. I’ve found a simple indicator for myself to be mostly emotional when I’m burnt out. When I’m burnt out, I invest quite a bit less of myself in my work, that is to say; I care less. That’s big trouble when it comes to building a product meant to help not only the client, but also potentially the customer base of that client. Working when you’re burnt out usually produces junk work; work that could have been so much more with your head in the game.

It’s a sinking feeling when I discover that I’m burnt out on work. On an average day, I’m usually neck deep involved with any projects in production and I’ll be able to focus all my energy on problem solving and getting things done. When I’m burnt out, my time would be better spent out of the office instead of forcing myself to make things happen.

If you’re able to decipher exactly what’s causing your burnout, whether it be impossible goals set upon you (or set upon yourself) or simply a lack of challenge, it’s great to nip that issue in the bud as soon as possible. Most of the time, however, burnout for me usually occurs at random, not as a direct reaction to anything in particular.

Combating burnout

There are a few things I’ve found that really help when I’ve discovered that I may be burnt out. Some things on this list can be generalized as basic stress relievers, but sometimes burnout can be quickly cured with a quick change in environment, you can take the list for what it’s worth.

Change projects

If your workload is anything like mine, you’ve got a list of projects to get done over the next few months. Sometimes I’ll find myself burnt out on a specific project at hand, and shelving that project for a day or two can definitely help with that. The only trouble is making sure impeding deadlines can provide this freedom. If you haven’t got too many projects coming down the pipe, take some time to work on something internal. You know there’s always things to get done for yourself.

Learn something new

If you’re burnt out specifically on the work you’re doing, I’ve found it helpful to expand your toolset. I mostly work on the front end of things, so when I get burnt out on working with markup & style, I’ll take some time to work on something to do with the back end. This complete change in environment usually gets my brain working the way I want. I’ll get stressed quickly due to my lack of knowledge, and endless references to books or other material will help me get things done, but after completion I’m ready to get back to the front end.

Clean up

I’ve got OCD when it comes to my desk. I hate a messy environment mostly because I feel it directly interferes with my productivity. If I’m burnt out on a project, I’ll take an hour or two to clean up around the office. An organized environment helps me to concentrate on work.

Watch a movie or read a book

We all love movies/books. Take the time to read that book you’ve left on the shelf for a year. Take the time to rend that movie you meant to see last summer. It may not live up to your expectations, but the distraction can prove to be invaluable.

Play video games

Many of us tend to be video game fans, and a few hours behind the controller can help provide the distraction we really need to help us concentrate when we sit back down to work.

Grab a coffee

It doesn’t have to be a coffee, but getting outside for a short while to grab a beverage will help. If you’ve got any coworkers you actually like, take them with you. Talk about anything but work and don’t sit back down until you feel like you can continue without hating every minute of it.

Sometimes, the only thing to help a Web designer or Web developer with burnout is to unplug, there are a few things I do when that’s the case:

Take a drive

While I haven’t spoken much about my personal pastimes, I’m what you could call a car enthusiast. I don’t have a race car in the garage I trailer to events on weekends or anything, but reading about, watching, and driving cars is something I’ve had an interest in for quite a while. Sometimes taking some time for yourself via a short (or long) drive can work wonders. Being in the car allows you to clear your thoughts to the road and your favorite music.

Take an afternoon off

Sometimes it won’t be until midday when I realize that I’m truly burnt out on work in general and the longer I remain at my desk, the worse it gets. I’ve found that recognizing unwarranted stress and taking an afternoon off will sometimes avoid a longer stint of burnout. The thing to do with your afternoon off is not something passive like going home and watching TV. Instead, go and do something. My token afternoon activity is detailing my car. It gets me away from computers in general and allows me to do some physical work. A few hours detailing your car can really clear your head and it’s often the first thing I’ll try to get done with an afternoon away from work, weather permitting.

Take a vacation

There will come a time where a few hours off just won’t cut it. If you find yourself in that boat, do yourself a favor and take a vacation. You don’t have to go anywhere, but don’t go to work. Spend some quality time with those close to you doing the other things you enjoy. Avoid work and computers in general for as long as possible and you’ll come back refreshed and ready to tackle what needs to be done.

What do you do?

I know my list is quite generic in the grand scheme of things, do you have anything particularly unique that you do when you’re burnt out at work?

Advertise here with BSA

I was excited about this project from the start, as was my team. We immediately started throwing ideas back and forth on what we could do to improve the customer experience for this particular storefront. A number of ideas were laid out on the table, some shelved for later phases of the project, and others tightly integrated into the overall design. I’d like to explain a bit about one feature in particular that ended up garnering quite a bit of the spotlight when the redesign was pushed live.

Color adaptation

I’d like to say that straight from the beginning the seed for this idea had been planted long ago with the publication of an article to A List Apart titled Super-Easy Blendy Backgrounds. Beginning with that article, my eyes had been opened to a new way of thinking when it came to Web design. While there were significant issues with PNGs in IE6, it was obvious to me that alpha transparency will indeed change things on the Web. That article, tied with a great piece written by Jeff Croft, Creative Use of PNG Transparency in Web Design, really got me hooked to the idea of using these unique advantages in upcoming projects.

The advantages of alpha transparency in the PNG image format are great in and of themselves, but for this project I thought we could take things one step further with CSS constants. I recalled reading a number of pieces on this specific subject and taking a liking to the idea. Quite a few designers feel that constants should be a built in feature of CSS, and I agree; it would be useful.

I had never implemented any CSS constant simulations prior to this project, but took comfort in the example with extensive documentation by Christian Heilmann. His sample was exactly what I was looking for.

I thought it would be completely awesome to tie these two features together; a color-changing template which uses a single color to ‘power’ the various shades and hues by taking advantage of alpha transparency by way of PNG.

When it came to the project I’d be working on, my company was merely in the discussion and planning phase with the client, I wasn’t 100% sure I’d be able to implement a feature such as this. I thought a bit about it and we decided it best to simply offer our proposal without specific mention of this feature. After successful test implementations, we’d mention to the client that we will be providing this additional functionality should there be interest.

I teamed with a single designer through the life of this project and he made the conscious effort to use only white and black in the design, but in transparent levels more often than not. He was able to use a solid color bottom-most layer in Photoshop to mimic how things would work in a Web browser. Our tests were quite successful and the idea was presented to the client. They fell in love with it and we began work. As you can imagine, cross-browser support was at times an issue, but I’ve got to say that overall the feature implementation was a very successful. Our client was able to offer an extremely versatile design to their clients, allowing them to customize the colors used throughout the redesign.

Extreme darks or lights

It became apparent almost immediately that we would need three separate variations of the same theme to account for variable choices on the part of our client’s clients. If a solid black background color were chosen, we’d need to make sure that all the design elements are equally visible throughout the design. The same applies for a solid white background color. At the end of the day, I ended up cutting three ‘sets’ of images: one for very dark background colors, one for very light background colors, and a third for mid-range colors.

The inclusion of this hurdle alone required some modifications to Christian Heilmann’s CSS constant simulation example; I had to account for the three ranges of color. The W3C published an algorithm to measure color visibility which I included in the CSS parser originally written by Christian Heilmann. I compared the color chosen as the background color to both black and white and measured the difference between. With some arbitrary testing, I included a tolerance variable which the client could adjust down the line if they’d like. The result came to be:

<?php
/*
	cssconst.php
	written by Chris Heilmann (http://icant.co.uk)
	allows constants to be used in the css
	file sent in the get variable c
	constant format:
	$foo='bar';

	Modification by Jonathan Christopher () to
	include a function to measure the color contrast of a variable set
	in the CSS. That value then sets another variable for use with image
	filenames.
*/

$background 	= '#8094b2';
$mainText 	= '#fff';
$altText 	= '#000';
$tolerance 	= 100;

$white = (hexrgb('ffffff'));
$black = (hexrgb('000000'));

function hexrgb($hexstr) {
    $int = hexdec($hexstr);
    return array("red" => 0xFF & ($int >> 0x10), "green" => 0xFF & ($int >> 0x8), "blue" => 0xFF & $int);
}

header('content-type:text/css');
//header("Expires: ".gmdate("D, d M Y H:i:s", (time()+900)) . " GMT");
$c=$_GET['c'];
$css=load($c);
if($css=='') { die('File not Found, sorry!'); }
preg_match_all("/\\$(\w+).*=.*\'(.*)\'/",$css,$constants);

// ---------------------------------
// determine color difference
// ---------------------------------

$targetHex = $background;

if(strlen($targetHex)==4) {
	$hexArray = str_split($targetHex);
	$targetHex  = $hexArray[1];
	$targetHex .= $hexArray[1];
	$targetHex .= $hexArray[2];
	$targetHex .= $hexArray[2];
	$targetHex .= $hexArray[3];
	$targetHex .= $hexArray[3];
} elseif(strlen($targetHex)!=7) {
	$targetHex = '#8094b2';						// worse case: use default
}

$color = (hexrgb($targetHex));

// Determine how different the color is from white
$whiteDiff  = max($color["red"],$white["red"])-min($color["red"],$white["red"]);
$whiteDiff += max($color["green"],$white["green"])-min($color["green"],$white["green"]);
$whiteDiff += max($color["blue"],$white["blue"])-min($color["blue"],$white["blue"]);

// Determine how different the color is from black
$blackDiff  = max($color["red"],$black["red"])-min($color["red"],$black["red"]);
$blackDiff += max($color["green"],$black["green"])-min($color["green"],$black["green"]);
$blackDiff += max($color["blue"],$black["blue"])-min($color["blue"],$black["blue"]);

if(!isset($image_suffix)){
if($whiteDiff<$tolerance) {
	$image_suffix 	= '-light';
} elseif($blackDiff<$tolerance) {
	$image_suffix 	= '-dark';
	} else {
	$image_suffix 	= '';
}}

// ---------------------------------
// apply background
// ---------------------------------
$css=preg_replace('/\\$background/',$background,$css);

// ---------------------------------
// apply suffix
// ---------------------------------
$css=preg_replace('/\\$image_suffix/',$image_suffix,$css);

// ---------------------------------
// apply mainText
// ---------------------------------
$css=preg_replace('/\\$mainText/',$mainText,$css);

// ---------------------------------
// apply altText
// ---------------------------------
$css=preg_replace('/\\$altText/',$altText,$css);

// ---------------------------------
// finish it up and echo
// ---------------------------------
$css=preg_replace("/\\#.*=.*?;\s+/s",'',$css);
echo $css;

/*
	Function load($file)
	reads the content of the file that you send and returns it
*/
function load($filelocation)
{
	if (file_exists($filelocation))
	{
		$newfile = fopen($filelocation,"r");
		$file_content = fread($newfile, filesize($filelocation));
		fclose($newfile);
		return $file_content;
	}
}
?>

If you’ll note, there are four variables to consider when using the above script. These variables were stored in a database and saved as a session variable server side. The $background variable controlled the overall color scheme used in the design by using it as the background color for the body as well as a few other strategic places where it was needed. $mainText was the primary text color used in the design, $altText was used in those certain circumstances where another color spiced things up a bit, and the $tolerance variable controlled how close a color had to be to either white or black before it was decided which background images were to be used to ensure proper contrast.

To implement the variables in the CSS, you simply add them as PHP variables:

body { background-color:$background; color:$mainText; }

The way I was able to distinguish which ‘set’ of images to use was partially twofold. My first step was to name each image accordingly. Much of the time, the same image itself could be, but there were other times were a black gradient on an image needed to me changed to a white gradient when a very dark background color was chosen. To get around the issue, I added a suffix to the filename of applicable images. For example, bg-body.png would have two additional images; bg-body-light.png and bg-body-dark.png. I was able to take advantage of this naming structure in both the CSS as well as the parser by referencing the images as something like:

div#example { background:$background url(../images/bg-body$image_suffix.png) no-repeat; }

All of my bases were covered. If the background was too dark, one suffix would be added in the parser, another suffix added if the color were too light, and the suffix would simply be empty if the color was middle of the line.

I hope it's useful to someone else

The inclusion of this feature turned out to be extremely useful in this case, and I hope others are able to take advantage of the idea. I'm sure there are endless ways to improve this specific implementation, so certainly feel free to offer both your thoughts and critiques.

Advertise here with BSA

A very common subject I find myself focusing on is that of communication skills & methods most appropriate given various situations. When I first began professional work, I had absolutely no idea what it was like to work with a (paying) client, trying to convert their ideas into a reality happily paid for. At first it was a struggle, I asked the wrong questions, made the wrong assumptions, and often found myself backtracking on work which was already nearly complete. Over time, a number of things have helped me to better communicate with clients not only for my benefit, but for their as well. It’s much nicer to work with happy clients as opposed to clients who feel they’re unable to properly communicate their reactions or ideas.

Begin internally; have a system

If you work at an agency or on a team, it’s really important to have an internal system of communication. A major obstacle I found myself dealing with was having a lack of resources when it came to me working on a particular project. When working on a team, it’s extremely difficult to keep mental records of every piece of communication, every note, every Word document that was sent to or received from a client. It’s not anyone’s fault, but sometimes various pieces of correspondence may fall through the cracks only to be found after a duplicate request is made to the client, putting you in an awkward position to answer the question “Why do you need [that] again?”. Tie in multiple projects and you can have quite a big stress on yourself in keeping all project material in place.

There’s a reason Basecamp is so popular. Basecamp removes any necessity for a company member or client to ensure anyone and everyone is on the same page with a project. My team has latched on to the ideology of Basecamp through the open source alternative, activeCollab (now forked to ProjectPier), and we’re not looking back. All client communication now takes place through various message threads which the entire company (as well as client participants) can read at any time. Using a collaboration system such as Basecamp or ProjectPier puts responsibility on each person for their own involvement and education for each project.

Being Explicit

With an effective communication system in place, it’s important to ensure your ideas and thoughts are properly communicated both to colleagues as well as clients. Being explicit in your choice of language can greatly affect communication.

A major priority should be to have your team members be on the same page. If there are details which need to be worked out, take care of that behind the scenes, before presenting your opinion/response/reaction to your client. That way, your team can be on the same page to both explain and support your stance on any particular matter.

Additionally, I’ve found it to be really helpful to include full documentation of your thought process behind any design decisions you’ve made. No matter what, clients are going to have preconceived notions about a project before it begins. They’ve got bias toward various elements, colors, or fonts that are going to shine the instant they see the first comp you present. It’s disheartening to hear that a client simply doesn’t like something you’ve produced, so there are a couple things you can do to help avoid complete rejection of a design you present.

It’s become practice in my office to include a (fairly detailed) write-up in support of a design presented to a client. It’s nothing extraordinary, just a document outlining the thought process of the designer which explains why various design elements appear as they do. Having this document to back up a comp has proven to be quite helpful in deterring a completely negative rejection. While not infallible, this document can provide insight on ideas not completely obvious to a client upon their initial inspection.

Fighting the good fight

If you’ve spent an hour doing client work, you know it’s inevitable to receive at least some (possibly ridiculous) suggestions from clients. Suggestions can range from listing a specific font to use to all out art direction. Nothing against clients, but most often these suggestions reflect nothing but a personal bias on their end and do little to improve a design. I’ve noticed that the handling & response to these suggestions can have great affect on the end product.

Many times a designer will read a criticism of their work and become defensive, wondering why the client wants to make a change that’s an obvious detriment. It’s often questioned whether the client truly wants an impressive end product. Of course they do, but of course there will be creative differences as to the degree of that impressiveness. It’s very rare that clients love everything presented to them and that should be kept in mind throughout the design process.

By far, I’ve found the most effective response to outrageous requests to be a simple inquiry of what lead to the request. More often than not, any inspiration for the request will be undefined, leading the client to recognize their poor decision. Initiating the dialogue can be simply saying something to the order of “That’s an interesting idea, what would be the reason for this particular change?” Usually you’ll end up hearing an unsupported response identifying a particular bias to which you can respond with (sound) design reasoning.

On the other hand, sometimes a response can be something you didn’t expect, something that does make sense to work with. While it may not be as aesthetically pleasing, you’ll be able to take their suggestion and work with them to find a solution acceptable to both parties.

The thing to keep at the forefront is that you and your client have a common goal; you’re not enemies. While creative differences may apply some stress to the project, it’s only because both parties care about what results. Try to keep that in mind as you volley communication back and forth about a comp which may have not had the amazing impact you hoped for.

Communication can always be improved

Although I’ve tried to optimize communication patterns in as many ways as possible, I’ve found that (like Web design & development) experience is the best thing you can do. Use your experience to alter the way you do things to improve your communication process both internally as well as with clients. Effective communication leaves much more time to do what we love to do, create.

Advertise here with BSA

This article, like many from A List Apart, really stuck in my mind as something quite innovative and useful; I just needed the right time to apply the technique. Super-Easy Blendy Backgrounds was published November 13, 2006 and I hadn’t come across a project to really make use of the technique until a few months ago. As the project was just coming together, Super-Easy Blendy Backgrounds instantly came to mind as a major time-saver for this particular client project.

Instantly, I was terrified of making things work in IE6. While you can use the AlphaImageLoader Filter, I know there would be some major issues as the project carried into development. There were.

Things to keep in mind with PNG background images and IE6

While the article published to A List Apart was extremely comprehensive and detailed, I went about things a bit differently. Super-Easy Blendy Backgrounds used inline images to achieve the desired effect, and I wanted to use background images. The effect was masterful everywhere except IE6, which is where the work began.

There were two major problems I encountered very quickly when working with PNG background images and IE6. The first problem I discovered was huge. When using AlphaImageLoader, links will not behave as expected in IE6. You’re stuck with a link that does absolutely nothing. I ran across multiple articles regarding this issue, many with varying circumstances and solutions for the bug. The solution that worked indicated the bug can be alleviated by ensuring the element using AlphaImageLoader has no position set and the anchor within said element does have a position. There were other solutions offered elsewhere, some indicating that the bug is triggered by the actual dimensions of the image you’re using as a background, but that didn’t help me as the images I were using were quite unique. It’s important to be aware that this may not always solve your problem. There may be times where you’ll simply need to find an alternative solution to this major problem with IE6.

The second major problem I came across was trying to tile background images for elements. Using AlphaImageLoader this simply isn’t possible. You’re forced to either crop or scale the background image. Using background-position or background-repeat is not an option. This forced me to use larger images in certain places, as well as use GIFs in other areas. You are able to set the sizingMethod to crop, but that may not be entirely useful.

How did things work out?

I’m quite pleased with how this project is turning out. Using PNGs effectively throughout the design will help this particular client adapt a single design by creating many color combinations by changing a couple variables on their back end. While the IE6 version of the design isn’t nearly as attractive as when it’s rendered using a fully capable browser, it degrades quite nicely and many of the features remain in tact.

The important thing to keep in mind when using techniques not fully supported cross-browser is to thoroughly test; especially for client work. How have your experiences been with using PNG?

Advertise here with BSA

Better control browser defaults

In part 1, I mentioned that controlling browser default styles can really help cut down your styling time. Using the universal selector, you can clear any default margin, padding, or border with a single line of CSS. While this tends to help out quite a bit with browser defaults, there is quite a bit more you can do.

As I’ve written before, I keep a copy of Eric Meyer’s reset CSS lying around to take care of browser defaults as opposed to using the universal selector. His optimized stylesheet comprehensively controls much more than something like:

* { margin:0; padding:0; border:0; }

I’ve found Eric Meyer’s solution to be much more helpful and stable in practice, and I’d suggest that you give it a try to see if it helps you out during your styling process.

Give yourself an applicable head start

A reset stylesheet can be an absolute time-saver. When doing client work, saving yourself some time here and there is becoming more of a necessity. In my personal opinion, when comparing design and development time on a project, development time should be kept to an absolute minimum while design time is maximized.

That doesn’t go to say that I feel development comes secondary to design; on the contrary. The difference between the two resides in the nature of each. Development is something that can be sped with each project. As nuances and speed bumps are overcome, a developer can significantly decrease the time it takes to produce high quality markup and style for each document they’re working on. Efficiency can be increased quite a bit simply by building more websites.

Design is a bit different in the sense that each project brings in a new set of rules. Each project is solving a different problem, circumventing new limitations, and providing quality solutions. Development usually presents itself with a constant set of conditions, which can be learned, expected, and avoided from the start if necessary.

As a result of this difference between design and development, there are ways to decrease development time, allowing for an increase in design time to remain in a limited budget. One way to help yourself to decrease development time is to use a CSS framework.

CSS frameworks were an extremely hot topic late last year, and I think all that needed to be said in their regard has been discussed (at least twice). I think the major difference in opinion rooted from the misunderstanding & assumption (mine included) that CSS framework proponents were pushing a single CSS framework upon others; that wasn’t the case.

I use Eric Meyer’s reset stylesheet on my projects. I use a CSS framework. Although it’s very limited in size, it fits the qualifications of a framework. As I mentioned earlier, reset styles help me to be more efficient at work, and finding a solid starting point for yourself with CSS can help you as well.

Control your clearing

In my experience, the most troubling aspect of CSS to grasp for newcomers is floating elements. When trying to help those new to CSS, trying to explain when to expect certain behavior can be a very frustrating experience for those new to CSS. Keeping that in mind, controlling your floating elements can really help alleviate a headache or two down the line.

Some time ago, Robert Nyman wrote a post explaining a few ways to clear CSS floats without extra markup. The post is great as an overview of some different techniques for clearing your floats. There are some great comments to read as a follow-up as well, and the piece as a whole can really help keep your floating elements under control.

Adding to the recurring theme, building more websites will help the most to learn when to expect a need to clear a float.

Separate page-specific styles

This tip may be less applicable, as it really only comes into play with larger websites with a bigger design budget. Something I’ve found myself doing quite often is physically separating page-specific CSS from the bulk. This involves incorporating both a pagevar as well as a pagegroup for each page of a website, which applies an id and class to the body of every document.

This gives me plenty of control should I want to target a group of pages (or specific page) with CSS. What’s important is to keep things organized; separating page-specific CSS can help significantly with maintenance, especially if your CSS is well commented.

Limit your refresh frequency

When I was first learning CSS, I quickly fell into the habit of refreshing the browser after nearly every selector was given a property and value. Soon enough, I would write a line of CSS, knowing exactly what it was going to look like, yet I’d refresh the browser anyway. Just to make sure I suppose.

Taking a step back to look at things, consistently switching apps and refreshing the browser to see how things are going can slow you down significantly. It’s important to learn to trust yourself as you become more proficient with CSS. Trust that what you’re styling is going to behave as you expect, and limit your refresh frequency as much as you can.

The trouble comes with writing too much and not knowing where to start compensating. This comes with the territory, and will remedy itself as you build more websites.

Refine your selectors

Finding the happy medium with specificity can be of great benefit. While you want to know which elements you’re targeting with CSS, it can really help to take advantage of specificity by keeping your styles to a minimum.

Difficulty may be found earlier in your development career in that you’re not sure why a certain element is improperly rendering. You’re sure of your CSS, sure things are as they should be, yet the browser renders something glaringly different. Chances are you haven’t found a quirky rendering bug (although I’m sure we can all agree we wish we had), but something is going on with your specificity. Styles are inherited when applicable, and this can be taken advantage of to a very high degree. The key is to specify to the proper degree, ensuring your control over the document presentation.

Closing up Part 2

I hope these tips, while a bit simple, helped out. CSS is a fantastic skill to have, but it is a skill which can be constantly refined over time. Keep in mind that the faster you are with development, the more time can be spent on problem solving by way of design. This allows for a wider variety of circumstances under which to fall when developing, as opposed to finding repetition in your work.

Advertise here with BSA