Website Testing: Conquering Cross-browser, Cross-platform Woes

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.

Basic Development Goals

First, my basic development goals for this redesign project:

  • Standards-compliant for XHTML 1.0 Transitional, CSS 2.1
  • WCAG-compliant (W3C’s Web Content Accessibility Initiative), preferably Priority 2 or 3, but at least Priority 2
  • Use of liquid widths, not fixed widths, for the entire layout
  • The visual display doesn’t need to look identical in every browser, even the latest browsers.
  • The visual display should look the best in the latest browsers and degrade gracefully for older browsers so that even users with old browsers can read, navigate, and use the website.
  • Use CSS workarounds or hacks only as a last resort, maintaining W3C validation, such as those listed at Peter-Paul Koch’s site, CSS Hacks: Safe List and his article at Digital Web, Keep CSS Simple.

Design and Development Approach

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:

  • Float problems, as explained at Position is Everything’s The Float Model Problem.
  • IE’s 3-pixel text shift problem, as explained by John Gallant and Holly Bergevin via Position is Everything’s The IE Three Pixel Text-Jog and via How To Attack An Internet Explorer (Win) Display Bug.
  • Jumping text when a link is hovered, as explained by Ingo Chao via Position is Everything’s Quirky Percentages in IE6’s Visual Formatting Model—my section navigation links jumped to the left on hover. In addition, within the main content area, text a paragraph or heading below the hover jumped up(!), but I suspect it’s for a similar reason. I think I’ve finally resolved both problems, in part by designating my <div> containers with negative margins:


    The problem is totally resolved if I also add the same to the left padding:


    The W3C validator doesn’t like negative padding even though negative margins will validate, however. I removed all but one negative padding designation, and I think the bug is still gone, but I’ll be doing further retesting.

I then checked it with Lynx (text-only browser) and Netscape 4.x. So far so good.

Checking Colors

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.

Then a Print Style Sheet

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!

More Cross-Browser, Cross-Platform Tests

Finally, I checked several pages via BrowserCam, especially for Mac browsers, where I found frustrating problems:

  • Positioning problems in IE5.2 Mac make the pages difficult to impossible to read due to content floating over other content, such as the footer area with the bottom-of-page navigation and contact links that should rest at the bottom of each page. The bottom dark blue strip should span the entire width of the page, too. The visual display in IE5.2 Mac is not good.

    Explorer 5.2 Mac OSX 10 floats

  • The bottom navigation in IE4 Windows didn’t display as inline list items, in addition to floating up over the content area. The bottom navigation should be a fairly narrow horizontal navigation strip that spans across the bottom of the page, similar to the dark navy strip just below it, not the fat dark tan area with block list item navigation that’s rendered by IE5.2 Mac in the example below. There’s also the big white gap below the footer, too, that shouldn’t be there, of course! UGH!

    Explorer 4, Windows 98 bottom navigation mess

  • In Netscape 4.x, the “print only” version top-of-the-page logo graphic and the on-screen logo appear at the top of the page, along with no background for the topmast, so it looked horribly ugly:

    nn4.8 linux8 both logos

  • Konqueror 3.05 for Linux 8.0, moves the right column to the bottom of the page, overlapping the footer and making a big mess, to put it mildly.

What To Do About Old Browsers, Little-Used Browsers?

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.

Re-check Bug Lists

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:

Re-check Browser Stats

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:

  • Browser News by Chuck Upsdell, is one of the best places to find out the latest trends, stats, and summaries about them. You’ll also find links to plenty of resources for more information. I spent a little time reading the latest and following a few of the links to other stats.
  • Browser Statistics by Rendering Engine by John Haller culls stats from WebsideStory,, and TheCounter. As Haller states, “All three are imperfect, but together, they may cancel out some limitations. WebSideStory is very US business-centric. OneStat is more global. TheCounter is more geared to smaller sites.”
What are Other Current Opinions?

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:

Figuring Out Practical Solutions

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:

  • Linking styles and hiding styles, via Empty Spaces:

    <style type="text/css" media="screen"> @import url('path/to/style.css'); <style>

  • An approach via

    /* 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";

Browser CSS Bugs, Hacks, and Workarounds

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:

  • CSS Crib Sheet? posted November 19, 2003, by Dave Shea via his website, Be sure to review the comments for that post, too, as it’s an interesting discussion.
  • CSS Problem-Solving posted March 3, 2004, also by Dave Shea, which is somewhat of a follow-up to the above.

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, June 24, 2004.

Checking Visual Layouts via Online Screenshot Services

As I researched IE5 Mac info and testing, I learned of and tried some free Mac screenshot services online, including the following:

  • BrowserShots, a free screen capture service for several Macintosh browsers at 800x600 and 1024x768: Firefox 1.0.4, Safari 2.0, MSIE 6.0, Opera 7.54. As I write this post, there’s a 12-day turnaround time for screenshots, as there are lots in line ahead of you.
  • iCapture, free screen captures with Safari for Mac.
  • lixlpixel Screen Capture, free screenshots with these Mac browsers: Safari 2.0, Internet Explorer 5.2.3, Mozilla 1.7.7. The screenshot results are immediate, too—no waiting.

In addition, I also use BrowserCam, which is a commercial service:

  • BrowserCam is a fabulous service that I wholeheartedly recommend. While the free services above are free, they only do the top of the page with a limited number of browsers. If you use an anchor within your page, though, such as #footer and input your URL with the anchor, such as, you’ll get that part of the page. (Thanks to lixlpixel for that tip!) BrowserCam will take screenshots that cover the entire page based on page scroll increments, which is how I identified the footer navigation problems shown above, for example. In addition, BrowserCam includes quite a few browsers on multiple platforms.

Getting Ready for Launch

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.

Ah, Web Standards!

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.


Comments, Trackbacks: 7 so far. Add yours!

  1. I’m glad my service is able to help.
    But there’s one thing you write which is easily solved - if you need a screenshot of the lower part of your website, just add an anchor to your footer (or wherever you want your screenshot taken) and call you site with .

    well - at least it works at my screenshot generator page ->

    it *should* work everywhere...


    08:46 am, pdt15 August, 2005Comment by lixlpixel

    comment #1 permalink ·'; else echo '·'; ?>

  2. lixlpixel,
    Ah, but of course! Now that you mention the use of an anchor to capture other parts of a page, it’s so obvious! I added it in to the post above, too, with credit to you. Thanks for that tip. Much appreciated!

    10:40 am, pdt15 August, 2005Comment by Shirley Kaiser

    comment #2 permalink ·'; else echo '·'; ?>

  3. I took a similar approach in developing a PmWiki skin—it has low fidelity and high fidelity modes, and your browser determines which you get. It seemed like a reasonable compromise, especially since I’d already made sure that the source order was appropriate for unstyled viewing.

    Another, even more comprehensive list of CSS filters is at

    10:57 am, pdt15 August, 2005Comment by Bronwyn

    comment #3 permalink ·'; else echo '·'; ?>

  4. Nice read. Glad to see your writing again.

    09:54 am, pdt17 August, 2005Comment by Cody Lindley

    comment #4 permalink ·'; else echo '·'; ?>

  5. Thanks for another great article!...also for the plethora of screenshots and links to useful sources and services.

    Did you do any mobile testing (PDAs, phones, etc.)? That would make a very interesting article too. Do any of the browser-testing sites you mention do mobile screenshots, or did you test using either Opera 8’s "small screen" mode or the Small Screen Renderer Firefox extension? Just curious what your experience with these might have been?

    Thanks again—best of luck with your new site!

    09:38 am, pdt19 August, 2005Comment by David Sims

    comment #5 permalink ·'; else echo '·'; ?>

  6. Hi, David,
    In response to your question about small screen testing, I did test with Opera 8’s small screen mode and with my PDA using Avantgo’s latest browser. While the new site is easy to navigate and is all readable in Opera’s small screen mode and with Avantgo, I have the visual problem of the screen-only logo and print-version logo both appearing with these 2 tests. (I’ll include some screenshots with my follow-up post on this.)

    Adding a CSS media=handheld style sheet didn’t work in either of these, and the regular version Opera 8 ended up reading it and hiding the wrong header logo and serving a very simple page instead of ignoring the handheld style sheet completely as it should have done. So I removed it until I can do more testing behind the scenes.

    Looking around, I’m finding that browsers greatly vary in their support of different approaches to including or ignoring CSS for handheld media. I’ll write a follow-up post about this soon, hopefully with how I resolved this problem!

    At the moment, since the site is usable and functions fine with Opera’s small screen mode and via Avantgo’s browser, I’ve gone ahead and posted the new design live online. It’s just rather ugly with both those logos showing up via Opera’s small screen rendering and Avantgo.

    Also, at the top of the page, the "skip to navigation/search" link is white in Opera’s small screen rendering mode, making it tough to see. (I suspect many wouldn’t even notice it. I just happen to know it’s there.) In Avantgo, ALL links are blue on a white background, so that link is fine. Opera’s small screen rendering mode ends up using many of my style rules from other style sheets, though, even though I’ve designated them for screen media, so that’s the dilemma there.

    I’d like to get the 2 above problems resolved, though, hopefully by figuring out a way to serve appropriate styles for handhelds that Opera or other screen browsers will either not see or will ignore.

    A few places I’ve bookmarked to check out further on this:

    1. Retooling Slashdot with Web Standards Part II - discussion about the CSS handheld media and browsers via A List Apart,

    2. Pocket-Sized Design: Taking Your Website to the Small Screen, via A List Apart, written by Elika Etemad and Jorunn D. Newth, August 31, 2004,

    3. Authoring for Small-Screen Rendering (SSR) via Opera’s website,

    4. handheld media type test, via HTML Dog,

    5. HTML and CSS for Mobiles, blog post at HTML Dog June 14, 2004,

    6. Complete CSS Guide: Mobile Profile, via Westciv.

    7. Stylesheets for handheld devices, via CSS Discuss Wiki. One of the tips here is, "If you put the handheld stylesheet after the screen stylesheet in your code, then use 'display: none' for whatever you don’t want going to a handheld. You have a reasonable chance of hiding things even if the handheld tries to read the screen stylesheet."

    I’d tried putting the handheld stylesheet first. Seems like a lot of unnecessary work to put it last and use 'display:none' for whatever I don’t want going to the handheld, but I’ve seen this tip in a few places now. I also want to make sure screen browsers won’t read it and follow those directions, of course, including Opera!

    8. Targeting Small Screens, an insightful post by Stop Design’s Doug Bowman, December 16, 2004,

    9. IE stylesheet quirckyness [sic], discussion thread at Webmasterworld, beginning February 14, 2005,

    10. CSS Media Type Tests, by Lachlan Hunt,

    11. want a small-screen friendly web site?, post by Simon Woodside, June 18, 2004,

    As I mention above, though, I haven’t spent any real time figuring this out yet. I hope to work on this during the next few weeks, though, in my private test area. Maybe I’ll post some public testing on this, though, too.

    I also welcome and invite anyone’s tips about getting the handheld style sheet to work when it should and to be sure screen browsers ignore it. :-) Hopefully I can leave these comments open for a bit longer to allow for that here.

    04:01 pm, pdt22 August, 2005Comment by Shirley Kaiser

    comment #6 permalink ·'; else echo '·'; ?>

  7. Thanks for the additional info re: small screen display design.

    And your new design is GREAT!


    06:09 am, pdt31 August, 2005Comment by David Sims

    comment #7 permalink ·'; else echo '·'; ?>

This discussion has been closed. Thanks to all who participated.

*/ ?>