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:
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 containers with negative margins:
The problem is totally resolved if I also add the same to the left padding:#somecontainer{
margin-left:-3px;
margin-right:-3px;
}
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.#somecontainer{
padding-left:-3px;
}
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.
- 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!
- 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:
- 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:
- IE5 Mac - CSS Bugs and Oddities, via Empty spaces
- North Pole: A Structural CSS Positioning Study, an insightful tutorial on cross-browser CSS positioning by Adrian Senior for Community MX
- Position is Everything, a fantastic website resource for CSS bugs and resources by Big John and Holly Bergevin.
- Will the browser apply the rule(s)?, a terrific chart with more information, via Centricle.
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, OneStat.com, 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:
- Dealing with IE5/Mac, post at Orderedlist.com January 5, 2005, by Steve Smith.
- Important Mac browsers?, an email to the css-discuss list by Martin Alderson on 4 December 2004 13:01.
- HTML and Browsers: Game over for IE5.x - Time to drop support?, discussion thread at Webmasterworld.com beginning July 31, 2005, 1:40 am.
- IE5/Mac Mattered, post at sidesh0w.com December 16, 2004, by Ethan Marcotte.
- seems like css isn’t working in ie 5 for mac, formatting wrong..., discussion thread at wordpress.org, started 2005-05-31 00:57:18 by Ron Adair.
- When Can We Hide From IE5/Win?, post at SimpleBits, December 17, 2004, by Dan Cederholm.
- Clarification Regarding IE5/Win, follow-up post at SimpleBits, January 12, 2005, by Dan Cederholm.
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:
@import url('path/to/style.css'); - An approach via sidesho0w.com:
/* 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, mezzoblue.com. 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 Informit.com, 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
#footerand input your URL with the anchor, such ashttp://website.com/pagename.html#footer, 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.
Courtesy,
www.brainstormsandraves.com
