accesses since July 9, 1996
copyright notice
accesses since July 9, 1996Remember the 1950's? Hoola hoops and rebels with and without causes were in. 78rpm records and fountain pens were out. Eisenhower was President. The cold war was heating up. Cars were adorned with huge fins and 45rpm record changers were selling like hotcakes. And test patterns were familiar television commodities at the beginning and end of the television broadcast day.
Well test patterns are back and this time they're digital, and this time they're on the Web.
To most baby boomers, test patterns in the 1950's were frequent companions. The viewing days started late and ended early, so the chance of catching a test pattern (accompanied by the national anthem) at sign-on or sign-off was actually quite good. These distorted, symmetrical graphics were used by adventuresome home viewers and tv repairman alike to manually align the electron beams of the picture tube so that the image was properly rendered. Test patterns embodied the accuracy of our personal window into the broadcast ether. They certified that we saw Uncle Miltie as he really was - makeup, high heels, gowns and all.
Test patterns are now fulfilling essentially the same role that they did in the 1950's. Only now they are being used to determine the level of HTML compliance supported by Web browsers. Our own World Wide Web Test Pattern [http://www.uark.edu/~wrg/] is one such resource for advanced cybernauts and developers alike in their quest to keep their desktop in synch with the Web world around them.
The utility of the Web Test Pattern, and other compliance checkers, is due to one simple fact: there is no orthodoxy when it comes to HTML standards. Since the Web's inception, standards have been elusive.
It has been said that the Internet is anarchy that works. If this is true, then the Web is the ultimate fulfillment of that anarchy: multimedia splendor built around too many conventions and too few rules.
Let me put the problem in perspective. The Web is really a pair of "killer" protocols: HTML (HyperText Markup Language), and HTTP (HyperText Transport Protocol). One of these, HTML, is strongly influenced by client-side developments. The fact that a server can be set, with minimal tweaking. to provide any batch of bits that client Web browsers can handle is an enticement for developers and end-users to build new media, applications and file formats into their offerings. The point to remember is that servers are basically passive distributors of Web media, and that independence allows Web client developers and users to move ahead at a very rapid pace.
The first experimentation in stretching the envelope (or trying to burst it, depending on one's point of view) was Netscape's use of extensions to the HTML standards put forth by the World Wide Web Consortium and the Internet Engineering Task Force. Netscape's Web browser rendered such "enhancements" as background colors and background images, a wider range of type sizes, greater control over image alignment and sizing, embedded tables, and the infamous "blink" - none of which were (and most still aren't) in the official HTML standards. The proverbial toothpaste was out of the tube.
It wasn't long before industry giants Sun and Microsoft got into the act. Sun proffered, though it has since abandoned, its own Web client, Hot Java, which augmented basic HTML with the support of Java applets and script. Not to be outdone by Netscape, Microsoft countered with a Web browser which rendered another superset of standard HTML tags including background audio, colored tables, and the equally infamous scrolling "marquee". Netscape, in the meantime pushed forward with frames and plug-ins.
Meanwhile, the popularity of the Internet has spawned a bewildering array of Web browsers by minor players who just want to grab a piece of the Web development action. These are the pilot fish of the developer community who try to follow one or more of the big three as closely as they can while waiting either to hit it big or sell out to a service provider. These are tenuous times for the small Web developer.
Since HTML defines what can and cannot be done in a Web document, it's the key to the evolution of Web document appearance and functionality. As long as the document content stays within the range of MIME types acceptable to the server, it may contain just about any information at all - tags, anchors, media types, you name it. That's both good and bad.
The good news is that there is enormous latitude for content providers and developers to insert their interests and agendas into the technology. The bad news is that there is enormous latitude for content providers and developers to insert their interests and agendas into the technology.
HTML compliance has been a continuous problem for Web surfers and developers. At no point since the inception of the Web have users been assured that their browser will correctly render the documents and media as the authors' intended. I'll refer to this problem as WYSINWOTS - What You See Isn't Necessarily What's On The Server. The WYSINWOTS predicament is as old as the Web itself.
That's where the Web Test Pattern comes in.
Figure 1 is the homepage of the Web Test Pattern in its current incarnation (as of June 1, 1996). The splash page encourages navigation to one of three resources: the most recently added compliance tests, the main compliance testing cybersphere or background information. These are the resources most likely to be used by the frequent visitor, the infrequent visitor, and the newcomer, respectively. The "visitor's bureau" augments more-or-less standard CGI "welcome-message-plus-guestbook" fare with useful statistical summaries of the browser types and host operating systems of the Test Pattern users.
The core of the Test Pattern are the individual tests. Figures 2a and 2b illustrate the effect of a test on individual browsers. Figure 2a is an animated GIF file as rendered on NCSA Mosaic, version 2.1. Figure 2b is the same animated GIF file as rendered on Microsoft's Internet Explorer, version 3.0 beta. Although there is no way to tell from these still shots, Figure 2b is actually only one frame of an animation. The image in Figure 2a is all that there is for Mosaic - not only doesn't the browser animate the media, it doesn't reproduce the color of the first frame.
Figure 2a.Animated GIF file as rendered by NCSA Mosaic v. 2.1.
Figures 3a and 3b reveal the same differences with respect to Java applets. Java applets are self-contained executables which are downloaded and launched by the Web browser. As Figure 3a and 3b show, Microsoft's Internet Explorer isn't adequate to the challenge where Netscape's Navigator is.
The issue of HTML compliance is a thorny one. There is certainly something to be said for the steady, deliberative evolution of Web standards so that our zeal doesn't become our undoing. Conversely, there is an understandable zest to harness the capabilities of modern digital networks. HTML compliance headaches come from these opposing forces.
The Web Test Pattern is one such resource to help ameliorate this problem. The next time your browser acts up (or hangs up), give the Test Pattern a look. It's an easy-to-use, GUI-based, general purpose test bench for determining browser health.