Section II.1. What Is a Platform?

II.1. What Is a Platform?

The term platform has multiple meanings in web application circles, depending on how you slice the computing world. In its broadest sense, a platform typically denotes any hardware and/or software system that forms the basis for further development. Operating system developers regard each microprocessor family as a platform (Pentium or PowerPC CPUs, for example); desktop computer application developers treat the operating system as the platform (each Windows generation, 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 2.0 port or an IEEE 1394 "FireWire" bus).

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

Today's crop of DHTML-capable web browsers are far more than data readers. Each one includes a content rendering engine (either open-source or proprietary), one or more scripting language interpreters, security access mechanisms, asynchronous server data posting and retrieval capabilities (part of a technology commonly called AJAX), 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 the browsers used by visitors. Despite a certain level of interoperability due to industry-wide standards, you must be ready to treat each major browser engineand sometimes each version of each browseras 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. Unlike the "old days," a browser's brand name is less indicative of its platform than is the engine running inside that browser. For instance, the same engine powers browsers named Mozilla, Firefox, Netscape, and Camino.

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 differ 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 an undesirable way when displayed in the same browser on a Macintosh or a Unix-based system.

Despite the potential hassle of distinguishing platforms down to the microscopic level, today's DHTML developer has to be aware of essentially two overall platforms: standards-compliant and Microsoft proprietary. It's not an either-or proposition. In fact, if you intend to have your DHTML content run on a wide range of modern browsers, you will be forced to blend the two platforms together by applying as much standards-compliant code as Internet Explorer can handle, and then provide accommodations for the IE proprietary features.^[*] With this blending in mind, the next sections compare standards-compatible and Microsoft DHTML feature categories.

^[*] Developers who prefer a more Microsoft-centric view of their development would reword this sentence to imply that when other browsers don't support IE-only proprietary features, the developer should write the code to accommodate the other (standards-compliant) ways.