- Lovely to Look At, Repulsive to Code
- 2000: The Year That Browsers Came of Age
- Too Little, Too Late?
- Bad Browsers Lead to Bad Practices
- Confusing Sites, Bewildering Labels
- The F Word
- Compliance Is a Dirty Word
This chapter is from the book
This chapter is from the book
This chapter is from the book
2000: The Year That Browsers Came of Age
With the release in March 2000 of IE5 Macintosh Edition, the world (or at least that portion of the world that uses Macs) finally got more than a teasing taste of web standards. IE5/Mac supported XHTML, ECMAScript, nearly all of the CSS1 specification, much of CSS2, and most of the DOM. IE5/Mac was also able to display raw XML, although it’s not clear why anyone would want to do so. (Visit Bugzilla at http://bugzilla.mozilla.org/show_bug.cgi?id=64945 to see some of the approaches that uber-geeks have taken to address the problem of displaying raw XML in browsers.)
IE5/Mac: Switching and Zooming
IE5/Mac was so attuned to standards that it varied its display and performance according to the <!DOCTYPE> listed at the top of a web page’s markup—a technique called DOCTYPE switching, to be discussed in greater detail in Chapter 11. Put simply, with the right DOCTYPE, a page would display and function as web standards said it should. With an old or partial DOCTYPE (or none), the page would render in backward-compatible “quirks” mode, to avoid breaking non-standards-compliant sites—that is, to be kind to 99.9% of commercial sites on the web [3.6].
)
IE5/Mac also included a feature called Text Zoom [3.7] that enabled users to magnify or shrink any web text, including text set in pixels via CSS, thus solving a long-standing accessibility problem. Prior to IE5/Mac, only Opera Software’s Opera browser allowed users to shrink or magnify all web text, including text set in pixels. Opera did this by “zooming” the entire page, graphics and all—an innovative approach to the occasionally epic conflict between what a designer desires and what a user might need [3.8, 3.9, 3.10].
)
)
)
)
Netscape’s Bold Move
A flood of standards-compliant browsers followed the release of IE5/Mac. Netscape 6 and its open source code parent Mozilla supported XML, XHTML, CSS, ECMAScript, and the DOM across all computing platforms. It, too, used DOCTYPE switching and offered Text Zoom, and it was designed from the ground up to be a fully compliant browser.
To achieve full standards compliance, at WaSP’s urging, Netscape had boldly junked its existing Navigator/Communicator 4.0 browser and every scrap of legacy code that had gone into it, restarting from a clean slate. Building a new browser from scratch took far longer than upgrading an existing browser. Netscape lost considerable market share during the years of Mozilla/Netscape 6 development—which began in 1998 but did not produce a commercial product until late 2000 (and arguably did not produce a viable commercial product until 2002).
These managers and engineers were not crazy. They obviously believed, as WaSP did, that the new browser would be finished in about a year. When one year became two and then three, the managers and engineers hung in there with a heroic, if increasingly baffling, determination to see the job through to the end.
Many companies would have abandoned such a project, shrugged their shoulders, and released a nonstandard 5.0 browser built on legacy code rather than sacrifice additional time and market share to a fiercely single-minded competitor like Microsoft. Although shareholders have every reason to disagree, Netscape’s management and engineers deserve our thanks for placing interoperability and the future health of the web ahead of short-term benefits and their own interests.
The Floodgates Open
Opera 6 came next—no DOCTYPE switching and no DOM, but fine support for most other standards. Opera eschewed DOCTYPE switching because, alone among commercial browsers, Opera had always sought to display pages according to W3C spec. Therefore, Opera’s makers saw no reason to offer a backward-compatible “quirks” mode. (Opera 5 and 6 did not support the standard W3C DOM, but Opera 7, released in 2002, does, and so, of course, do all successive Opera versions.)
Finally, Microsoft released IE6 for Windows, a browser that mostly caught up with its Macintosh product’s accurate CSS rendering; that offered strong support for XML, ECMAScript, and the DOM; and joined IE5/Mac, Mozilla, and Netscape 6+ in providing DOCTYPE switching. (On the browser’s release, the Windows-centric trade press finally noticed DOCTYPE switching and gave IE6/Windows the credit for it.)
IE6/Windows failed to implement Text Zoom, but Text Zoom, although highly desirable from the point of view of accessibility and user friendliness, is an innovation, not a standard. (The ability to resize text did not become a W3C standard until 2002, with the release of the sexily named User Agent Accessibility Guidelines. See www.w3.org/TR/UAAG10/guidelines.html#tech-configure-text-scale for details.) IE6/Windows got CSS fixed-attachment backgrounds wrong, and it also suffered (and still does) from a multitude of bugs. But its compliance was good enough to be worked with—or around.
None of these browsers was perfect, but each was a major achievement that demonstrated genuine commitment to interoperability via standards. No one, least of all The Web Standards Project, had believed these companies would come so far or do so much. With leading browsers finally attaining a kind of parity in their standards compliance, designers and developers were free to use CSS layout and other standards-based techniques.