Why Don’t You Code for Netscape?

Q. Your website looks nice in Internet Explorer 6, but really bad in Netscape 4.7. Is this the type of web page design that you are recommending to your readers?  The worst problem is that it doesn’t even look like the same page!

By the way, the buttons that supposedly let the reader choose the font don’t work in NS 4.7.

As a web designer, it’s important to me that my site not only look good in both browsers, but that all readers will see the same design and formatting.

Please explain the logic of designing only for one browser.

Cordially,
[Name withheld]

A. Thanks for writing. We don’t design for only one browser. We design for all browsers and devices by authoring to W3C recommendations including XHTML 1.0 Transitional and Cascading Style Sheets.

As a result, A List Apart displays properly in Opera 5, Opera 6, MSIE5, MSIE5.5, MSIE6, Netscape 6, and Mozilla, while its text is available to any browser or Internet device, from Netscape 1.0 to Palm Pilots and web phones.

The logic of authoring to W3C recommendations, instead of to the quirks of old, non–standards–compliant browsers (be they Netscape’s or Microsoft’s or anyone else’s) is explained in these places:

1. The Style Guide of the Branch Libraries of The New York Public Library
2. To Hell With Bad Browsers here at ALA
3. The Web Standards Project’s Upgrade Campaign: Developer Tips

A List Apart uses The Web Standards Project’s Method 2: Invisible Object to make its text available to any browser or device, even if that browser or device does not support CSS or other web standards used in crafting the site’s simple design.

Problems with old web design methods#section2

Before the year 2000, no browser fully supported W3C recommendations, and we were all taught to write whatever non–valid markup was necessary to make our sites work in these browsers, without even considering the work of the W3C, and its goal of making sites interoperable and accessible to all.

Before W3C recommendations were in place {Ed. third-party article now offline}, and before browsers supported them, most of us had no choice but to design and develop our sites according to the proprietary quirks of each browser. But this method of working had at least four major disadvantages:

1. It made our sites inaccessible to people with disabilities.
2. It made our sites fail in some browsers, and stop working as browsers changed—for instance, if you coded for Netscape 4 layers, your site would not work in Netscape 6, let alone MSIE or Opera.
3. It made our sites cost more than they had to, since we spent so much of our clients’ money writing “workaround” code.
4. And by yoking presentation (design) to structure (content), it made our sites hard to transport to wireless and other alternative devices. By contrast, with valid XHTML and CSS as used at A List Apart, content reaches most wireless, handheld, and phone-based devices automatically.

Unfortunately, in late 2001, tens of thousands of professional web designers and developers continue to create sites tailored to the quirks of non–compliant browsers instead of learning about and using W3C recommendations designed to solve these problems and ensure continued interoperability and accessibility.

The goal of W3C recommendations#section3

The W3C created recommendations like XHTML and CSS so the web would not fragment into ever–more–incompatible browsers and devices, but would instead work for everyone, according to the vision of Tim Berners–Lee, the guy who invented the web in the first place.

The only way we designers and developers can help the web achieve this noble goal is by authoring to these recommendations, while taking care to ensure that the sites still work as best they can in non–compliant browsers.

Each site is different#section4

Of course, each site is different, and you must look at your referrer logs and talk to your client (or your boss, if you work in–house) to determine the optimal time for switching from old–fashioned, non–standard web design to W3C–compatible methods.

The method outlined in the NYPL Style Guide (valid XHTML, tables for basic layout, CSS for all else) works in any browser, though the design may be ever–so–slightly degraded in 4.0 and older browsers. I often follow this method in designing projects for clients, and recommend it in my consulting practice as a means of bringing document structure and forward–compatibility to large–scale content sites.

By contrast, the method used here at A List Apart (XHTML for structure, CSS for layout and design) ensures that every reader has access to the site’s text, but allows the design to “disappear” if the browser can’t handle it. No 4.0 browser can handle it.

We assume that those who choose to keep using 4.0 browsers have reasons for doing so; we also assume that most of those folks don’t really care about “design issues.” They just want information, and with this approach they can still get the information they seek. In fact, since we began hiding the design from non–compliant browsers in February 2001, ALA’s Netscape 4 readership has increased, from about 6% to about 11%.

A List Apart is a non–commercial site; we designed it this way to encourage other web designers to think about the web’s present and future, rather than always bending over “backwards” for old, non–compliant browsers.

If our sites are to endure, our development practices should look toward the future (XML, separation of structure from presentation) rather than the past (appearing exactly the same in every browser, regardless of the damage to document structure, interoperability, and accessibility).

For more information on web standards, visit The Web Standards Project and especially the W3C. The ALA articles linked in the “Related Stories” sidebar will also help.

Best of luck and thanks for writing.
Jeffrey