| abstract
| - When Tim Berners-Lee developed the first browser, named WorldWideWeb, it was also a WYSIWYG (What You See Is What You Get) or, as this article's title refers to the category, visual editor for HTML. In fact, Berners-Lee recounted: A similar concept is present in some IDEs; components are dragged into position with the mouse and their properties edited in a sidebar. And this process fits like a glove to the whole metaphor of an interface intended for mouse-oriented usage. So why do we discourage the use of such tools for HTML? After all, similar technology fields do it that way, and the very author of HTML and (widely regarded) primary founder of the Web intended it that way. The answer is: Because it doesn't work for HTML nearly as well as for those other fields. Now wait a second. How is HTML different from interfaces for, say, Java or C++ desktop applications? It doesn't assume a medium, such as a screen, a radio, or a printed book. The others are all about what can be displayed on a screen and clicked with a mouse. There are alternative ways to use them for the disabled or power users, but those can be implemented independently of how the components appear on a screen. Furthermore, the information they present is not expected to be available just anywhere, but only under such conditions as the vendor specifies it to be compatible with. As for Berners-Lee's expectations, the Web in general has become far more than he anticipated. It's not just a system for internal CERN communicades. It's not only used by technology professionals, nor adults, nor those without disabilities, nor even humans (or rather, software acting at the direct behest of humans as browsers do). It is displayed by graphical browsers, spoken by voice browsers, translated into a sequence of bumps by Braille browsers, indexed by search engines, and printed onto paper. Which of these occurs is irrelevant to the language; the media are responsible for adapting to it (with help from CSS), not the other way around. So how are we supposed to author pages make sense in any context while also taking advantage of the enhancements available for specific ones, such as Flash and JavaScript in graphical browsers? A bunch of eggheads gather periodically to discuss this issue, and their solutions are published as standards. User agents (browsers, search engines, etc.) implement those standards with a degree of variation, and the development community produces tutorials and advice (both good and bad) for how to author pages. If we develop to the standards and best practices using text-only editors, and test in a variety of user agents, we can fulfill the Web's potential for interoperability. Those details are covered in the tutorial.
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)