Cure for Plug-in Heartbreak
By Charlie Cho
What seemed unthinkable during the great 4.x browser wars will soon be upon us: Browsers finally support a cluster of World Wide Web Consortium (W3C) recommendations, which were finalized late in the twentieth century. Developers will find it easier to work with standards like HTML 4, XHTML, Cascading Style Sheets (CSS), and Document Object Model (DOM).
Also included in the mix is ECMAScript, a standardized, core JavaScript specification. Most browsers' JavaScript implementations are already ECMAScript compliant. This ubiquity makes it the default language for accessing and manipulating page elements via the DOM. Dynamic HTML, or DHTML, is the common rubric for fine-grained control over page appearance and function.
Prior generations of browsers featured incompatible DHTML implementations of varying quality. (JSS, anyone?) Those brave enough to use these features often found themselves writing multiple versions of a page to support different browsers, or to support only one browser type, letting users of other browsers eat cake. This impasse provided an opening for proprietary technologies implemented as browser plug-ins to position themselves as solutions for enhanced Web content. While plug-ins serve a valuable purpose, particularly for multimedia, content developed for them is not universally viewable. Platform dependencies and content encased in proprietary technology crept onto the Web in an ugly way. Worse yet, these technologies were often used to create solutions that could have been handled by DHTML. In particular, certain uses of Java applets and PDFs come to mind.
