Website Testing: Conquering Cross-browser, Cross-platform Woes
09:08 PM - Aug 14, 2005
As I was doing final cross-browser testing for a redesign of SKDesigns, my website design business, the design implementation was working quite well in nearly every mainstream browser for Windows, Mac, Linux, and even the Lynx text-only browser. Unfortunately, though, I found problems with three old or little used browsers, such as Internet Explorer 5.2 for Mac that destroyed the CSS-positioned layout. I toiled over how to best handle these browser bugs, especially since my upcoming Web design book—currently in production at my publisher—stresses the importance of usability, readability, and degrading gracefully for older browsers. Today’s post covers part of my decision-making journey and choices of approaches for dealing with these CSS bug-riddled old and little-used browsers.
First, my basic development goals for this redesign project:
I kept in mind the above goals while I created the visual design. Here’s the basic skeleton layout upon which I created the design and markup:
skdesigns basic layout
As I also recommend in my upcoming book, I first developed the design for the homepage to validate to W3C Recommendations, which in this case was XHTML 1.0 Transitional and CSS 2. I then checked it with Opera 8 and Firefox 1.04 since they support CSS 2 the best at the moment. Once those worked, I checked it with Internet Explorer 6, finding plenty of problems due to several of this browser’s frustrating CSS bugs, such as the following:
#somecontainer{
margin-left:-3px;
margin-right:-3px;
}
#somecontainer{
padding-left:-3px;
}
I then checked it with Lynx (text-only browser) and Netscape 4.x. So far so good.
In addition, I checked the visual design on several different displays to see how the colors looked on a variety of displays. On one computer’s display, the topmast’s heading background looked incredibly washed out rather than showing the rich colors that I had in mind. The colors looked as intended on my own computer’s display set to the sRGB standard. I went back to Photoshop and did some serious color revisions to try to better compensate for other displays.
When all that checked out OK, I then created a couple of internal pages and retested, repeating until I’d created all the pages.
At that point, I went ahead and created a simple print style sheet. As you’ll see in the Netscape 4 example below, the on-screen top heading’s logo image is a transparent .gif image that floats over its topmast area dark multi-colored background, but its edges appear jaggedy without its needed dark background, as I expected. I created a different version for print that works for a white background. I stipulated in my CSS to hide for screen and show for print, and likewise to hide the screen version in my print style sheet, such as:
In my screen style sheet:
#logoscreen {display:block;} /* screen logo */
#logoprint {display:none;} /* print logo */
In my print style sheet, the opposite:
#logoscreen {display:none;} /* screen logo */
#logoprint {display:block;} /* print logo */
I tested the print version by clicking on Print Preview in Firefox, Opera 8, and IE6, where it worked as expected. I didn’t check it in Netscape 4 at that point, though, which bit me later, as I explain below!
Finally, I checked several pages via BrowserCam, especially for Mac browsers, where I found frustrating problems:
Explorer 4, Windows 98 bottom navigation mess
Next came deciding what to do about these problems. My bare minimum requirement is to be sure the site is still usable and readable in the above problem browsers. The above problems didn’t meet that, as shown in those screenshots.
First, I thought I’d re-check bug lists to see if/what I’d forgotten to allow for that I hadn’t already covered. Some insightful online resources are:
Next, I decided to check the browser stats for IE5.2.3 Mac, Konqueror 3.x for Linux, and the latest for IE4.x and Netscape 4.x. Even 1/2% or 1% using any of these still means 300-600 visitors to my business site each week who wouldn’t be able to read the content or navigate through the site, which is not OK with me. I wanted to at least meet the minimum.
At the same time, these browsers have plenty of bugs and oddities, and I really didn’t want to spend a lot of time with this or mess up my CSS for the most-used mainstream browsers.
To make sure the stats numbers in my head were still current, I re-checked my site’s browser usage statistics and other freely available browser stats and general trends. I especially wanted to find out the numbers of visitors using specific Mac browsers, and how the trends are going. I also know that stats aren’t totally accurate, so checking several sources gives me a broader picture, not just what my own site visitors use in any given week. Here are a couple of helpful resources:
I also wanted to see what others are doing about these browsers, especially IE5.x for Mac and Windows. Here are some resources that I found helpful:
Given the numbers are so small and diminishing as the weeks go by, I decided to serve these old or little used browsers a visually simple website that’s readable and navigable, although it won’t have the visual design seen in current mainstream browsers.
First, I thought I’d try an approach to hide style sheets from IE5 Mac. That way I’d keep hacks and workarounds to a minimum within my style sheets. Here are some possibilities that I explored, the latter of which I chose to use for my site:
<style type="text/css" media="screen"> @import url('path/to/style.css'); <style>
/* comment here
\*/
@import url("stylesheet.css");
@import url("anotherone.css");
/* END hide from Mac IE5 */
After I tested that filter, I also added another filter to hide my style sheets from IE3-5 Windows, too: Tantek Çelik’s High Pass Filter. The result in IE5 Mac and IE3-5 Windows is a visually simple one, but it’s now readable and usable. In addition, I didn’t need to add any more hacks within my existing style sheets. I can live with this result for such a small number of visitors, especially since those numbers keep shrinking.
I created a simple style sheet for all browsers, but these old or little used browsers can see and use it without any harmful effects, including Netscape 4.x. The latest browsers can also use another more advanced style sheet that they can handle that’s hidden from these old or little used browsers via the filters. I might add more styles to the simple style sheet before I finish the redesign, but I haven’t decided on that yet. I can live with it like it is right now, too, especially knowing that those using these older or little used browsers can still use the site.
Along the way I found info on serving a style sheet only to IE5 Mac, for those interested in trying that. This is shown with a great explanation via Stop Design’s Doug Bowman at IE5/Mac Band Pass Filter:
/*\*//*/
@import "ie5mac.css";
/**/
I’ve talked about hacks and workarounds a fair amount in this post, but I’m still a firm believer that it’s far better in the long run to create your style sheets without any hacks or workarounds first, and then only use them conservatively when deemed absolutely necessary. For example, you can do a lot to avoid many of the browser quirks and bugs by how you approach your CSS. There’s plenty of documentation around the Web about it, but here are a few:
If you’re creating your own site that you can monitor and change as new browser versions come out, you might not need to be as conservative, but if you complete a site for a client and you sign off on the project, it might be better to avoid hacks and workarounds, or at least keep them in a separate style sheet that can be more easily removed once they’re not needed.
Hacks and workarounds today may cause problems later. The next version of Internet Explorer is on the horizon, and other browsers will continue putting out new versions, too. The approach I’m really talking about here is coined “Progressive Enhancement.” See Steve Champeon’s article via Webmonkey: Progressive Enhancement and the Future of Web Design.
See also Integrated Web Design: Strategies for Long-Term CSS Hack Management, by Molly Holzschlag for Informit.com, June 24, 2004.
As I researched IE5 Mac info and testing, I learned of and tried some free Mac screenshot services online, including the following:
In addition, I also use BrowserCam, which is a commercial service:
My business site’s redesign is now almost ready to go. I’m in the midst of editing and updating all the content. I’ll do a final test of the entire site with CSE HTML Validator’s batch processing feature that checks for W3C validation, spelling, and links (really handy!). I’m planning to have it online live within a few days.
Well, the hurdles I’ve had to jump over for this one redesign are another example of why Web standards matter. While the above may sound like a lot to figure out, the above is nothing compared to the version 3 and 4 browser days and the lack of even decent browser support for W3C Recommendations. At the same time, designers and developers like myself also wish standards support could be a lot better than it is now. We have to keep after 'em and continue to push for it.
Interestingly, most mainstream users don’t even think about standards. They just want to visit a website and do whatever it is they came to do there. That’s how it ought to be, too.
Users shouldn’t have to think about standards at all, in my opinion. Standards should live quietly in the background helping to make everything work smoothly regardless of the browser or platform. In an ideal world, we designers and developers wouldn’t have to deal with all these browser bugs, either.
[Home: Mobile · Main]
