Cross-Platform Compromises (Dynamic HTML: The Definitive Reference, 2nd Edition)

2.1. What Is a Platform?

The term platform has multiple meanings in web application circles, depending on how you slice the computing world. Typically, a platform denotes any hardware and/or software system that forms the basis for further product development. Operating system developers regard each microprocessor family as a platform (Pentium, PowerPC, or SPARC CPUs, for example); desktop computer application developers treat the operating system as the platform (each Windows generation, Mac OS 9, Mac OS X, Unix, Linux, and the rest); peripherals makers perceive a combination of hardware and operating system as the platform (for example, a Wintel machine USB port or a Macintosh FireWire bus).

The de facto acceptance of the web protocols, such as HTTP, means that a web application developer doesn't have to worry about underlying network transport protocols. Theoretically, all client computers equipped with browsers that support the web protocols—regardless of the operating system or CPU—should be treated as a single platform. The real world, however, doesn't work that way.

Today's crop of web browsers are far more than data readers. Each one includes a highly customized content rendering engine, one or more scripting language interpreters, security access mechanisms, and optional connections to related software modules for media playback, Java applets, and the like. The instant you decide to author content that will be displayed in a web browser, you must concern yourself with the capabilities built into each browser. Despite a certain level of interoperability due to industry-wide standards, you must treat each major browser brand—and sometimes each version of each browser—as a distinct development platform. Writing content to the scripting API or HTML tags known to be supported by one version of a browser does not guarantee support in other browsers or versions.

If you are creating content, you must also be aware of differences in the way some browsers tailor themselves to each supported operating system. For example, even though the HTML code for embedding a clickable button inside a form is the same for any forms-enabled browser, the look of that button may be vastly different when rendered in Windows, Macintosh, and Unix versions of a particular browser. That's because some browser makers observe the traditions of the user interface look and feel for each operating system. Thus, a form whose elements are neatly laid out to fit inside a window or frame of a fixed size in Windows XP may be aligned in a completely unacceptable way when displayed in the same browser on a Macintosh or a Unix-based system.

Even though much of the discussion in this book uses "cross-platform" to mean compatible with both Netscape and Microsoft browsers ("cross-browser" some might call it), you must also be mindful of operating-system-specific details. Even the precise positioning capabilities of "cross-platform" cascading style sheets do not eliminate the operating-system-specific vagaries of form elements and font rendering. If you develop applications that rely on DHTML, you can eliminate pre-Version 4 browsers from your testing matrix, but there are still many browser and operating system combinations that you need to test.

I now examine the predominant DHTML browser platforms. They are presented in chronological order of their release to the web-surfing public. The following material is required reading for all DHTML developers, even if you believe you need to develop for only one platform. As you will learn, the lines between platforms are not as clearly drawn as they once were.

Chapter 2. Cross-Platform Compromises

Contents:

2.1. What Is a Platform?