|
Browser Window column #2
XML, Access, and the Hypertext Holy Warby Michael Macrone Keeping up with the high level of Web excitement is getting to be exhausting. Maybe I just peaked with Dynamic HTML, but I can’t seem to muster what appears to be the requisite enthusiasm for this year’s revolution, Extensible Markup Language. You know it better as XML, though chances are you still don’t know what it means. I don’t blame you, since XML is one of the fuzziest Web concepts yet, referring to a high-level system, or metalinguistic structure, rather than to an actual language. It’s not a set of tags and rules, but a set of rules for creating tags and rules. Which means that it’s less like HTML than like a license for making up any sort of ML you want. In the ether that XML inhabits, practically anything is possible, but the vapor is also thicker. I’ve heard proponents promise everything short of a format that delivers your lunch. The reality is likely, as always, to look a bit different. As far as I can tell, XML will amount in practice to building a better shopping cart. Well, okay, it will also mean better search engines and maybe better “channels,” and also the (slightly sinister) integration of different companies’ databases. This is the sort of stuff that thrills the hearts of back-office types, but which, if you’re an author or designer, probably doesn’t do much for you. And I hope you’ll forgive my skepticism on the topic of reliable browser support, let alone consistent implementations. But you probably still don’t know what XML means. Let’s turn for clarification to a recent feature on CNET’s developer Web site, BUILDER.COM [now absorbed by ZDNet]. In “20 Questions on XML,” Trisha Gorman notes that the World Wide Web Consortium (W3C) calls XML “a common syntax for expressing structure in data.” She continues: Structured data refers to the data that is tagged for its content, meaning, or use. For example, whereas the <H1> tag in HTML specifies text to be presented in a certain typeface and weight, an XML tag would explicitly identify the kind of information: <BYLINE> tags might identify the author of a document, <PRICE> tags could contain an item’s cost in an inventory list—all the way down to <DOGFOODBRAND> if that’s the level of detail required. In other words, XML allows data to be tagged according to semantic rather than presentational rules. This certainly sounds like progress, except that everybody seems to forget that such was also the intended purpose of HTML. Indeed, <H1> precisely does not “specify text to be presented in a certain typeface and weight”; while the tag might have that effect in the major graphical browsers, it is actually a semantic marker: “The following content is the primary heading of this document.” (Likewise, <H2> tags headings of secondary semantic importance, and so forth.) Netscape Navigator and Internet Explorer both happen to present primary headings in 24-point Times Bold, but that’s the browsers’ doing, not HTML’s. Text-based browsers such as Lynx, not to mention non-visual presentation systems, have entirely different rules for how to differentiate the contents of an HTML document. Ms. Gorman goes on to explain that by “separating structure and content from presentation,” the same XML source document can be written once, then displayed in a variety of ways: on a computer monitor, within a cellular phone display, translated into voice on a device for the blind, and so forth. Again, if this had been written in 1995 rather than in 1998, everyone would have assumed she was talking about HTML. In its original conception, HTML promised the same sort of portability and platform-independence. So what went wrong? The answer, unsurprisingly, depends on whom you ask. Some would say that HTML, if carefully and strictly written, still functions perfectly well as a descriptive, portable, and display-independent markup language. XML, because it is customizable (“extensible”), will allow for more specific markup, and thus for more precise access and scripting. But its boast of portability is just old wine in a new bottle. However, there’s no denying that strictly descriptive (structural) HTML is a rare commodity on today’s Web. (How many people still use <STRONG> in preference to <B>?) The main argument is over whether this is a good or bad development. Actually, “argument” is too weak a word. On the Usenet, it’s called a “holy war.” The war began with the emergence, and increasing dominance, of graphical browsers. Mosaic, the first, added support for inline images, making pages more visual. And it defined the basic rules for giving HTML structures a graphical representation—<H1> translated to a large, bold, proportional typeface, <P> to a double line break, <EM> to italics, and so forth. Netscape, led by Mosaic programmer Marc Andreeson, adopted the same conventions, as did Internet Explorer, another Mosaic spin-off. Markup would produce essentially the same visual result in any of these browsers. Once graphical effects became practically identical to structural causes, people naturally started using markup for page description. In other words, authors began to use tags to spec type—as a means to a graphical end, rather than a means to more meaning. <H1> came to signify “24-point Times Bold,” not “this document’s primary heading.” <BLOCKQUOTE> meant “indent by 40 pixels,” not “a block of quoted material.” And why not? Authors have a natural desire to control how their work is presented. Purists will claim that presentation doesn’t, or shouldn’t, matter, and that attempts to control it are “abuses” of HTML. But this is naive. True platform- and thus presentation-independence is only possible when content has no shape, or is indifferent to its shape, or, in sum, has nothing to do with how the user receives it. Such a notion hasn’t been taken seriously for two centuries. But what the purists in this holy war really mean is actually just the opposite. One soon discovers, in reading their arguments, that presentation turns out to matter quite a lot. Only they think that they, rather than authors, should control it. Or, short of writing their own browsers, control what they can: default fonts and colors, relative type sizes, display width, window size and shape, whether to display images or multimedia, whether to run scripts, etc. So the argument is less about the “abuse” of HTML for visual ends than about what’s now called “access”—the degree to which a page does or doesn’t impose conditions on users. What’s accessible (user-friendly) of course depends on the user, but it also depends on the purpose. The purpose of a price list differs from the purpose of a Hollywood “micro-site.” Their audiences will also differ, and with them the meaning of access. It’s not so much whether an author should control the display, but to what degree he shouldn’t. On the one hand, users should be able to view columns of data at whatever size and width makes them comfortable. On the other hand, even price lists benefit from basic design principles that the author may know better than the user. And as for sites whose whole point is to provide a visual experience, those who wish to enjoy them may have to adjust their screens. Some people never want a Web page to ask them to do anything. Warnings that a page is “best viewed at 800 x 600 with Netscape 4” drive them into a rage, and one sometimes sees their point. Access becomes an issue when one feels denied it, as many were by a recent Disney site (www.disneyblast.com), which locked out non-Windows browsers. Instructions to download a plug-in can also be irritating, as can poor design—which, given the average coder’s design skills, abounds. Even skilled authors and designers can learn from the rantings on such Usenet groups as comp.infosystems.www.authoring.html (“ciwah”), a leading candidate for the major newsgroup with the longest name. Just because something’s possible in HTML or JavaScript doesn’t mean it’s always appropriate, and users’ anger can be instructive. For example, I learned the hard way to avoid background audio where possible; whenever I tried it, I took a lot of heat in e-mail from people with SoundBlaster cards and sleeping spouses. Looping sound clips can be mesmerizing, but on repeated exposure they grow so annoying that users will start avoiding your site. The best approach with sound is to at least provide a way to turn it off, if not the choice to turn it on in the first place. Another hot button is control of the GUI. From the very first, JavaScript allowed authors to open and modify new windows, with precise dimensions and with or without some of the “chrome” (menus, scrollbars, resize handles, etc.). This predictably spawned complaints from those who preferred to open and resize their “own damn windows,” as one poster to ciwah has put it. But whether or not all users liked it, authors loved it, so the pop-up window is a pervasive and likely permanent fixture. Grumbling has also failed to prevent browser developers from giving authors ever more control of the GUI. The scripting engine implemented in the latest browsers allows access not only to the properties of new browser windows, but even to those of a viewer’s primary window. Before, if a user started browsing with a window set to 500 x 300 pixels and centered on the monitor, that’s where it stayed. Annoying pop-up windows could always simply be closed, and the user could then move right along to some other, more “accessible” site, with his main window in its preferred position. Not any more. It’s now possible to move and resize any open window, even if it’s the only one. This means the user must manually resize it or close it, which, on Windows platforms, quits the application. (Mac users, meanwhile, lose their default window settings.) It’s even possible to make a window unresizable, a trick I’ve had fun testing out, but one I’d be loath to spring on the general public. If you’re curious as to how resizing works (and promise not to blame me for the fallout), here’s a quick example that will work in both Netscape 4 and Explorer 4. It relies on the new JavaScript screen object, which measures the user’s display resolution. In particular, screen.availWidth returns the usable display width in pixels, and screen.availHeight the usable display height. If you pop this in the HEAD of any HTML document, it will resize the window to fill the entire screen once the page is done loading. One can imagine good uses for this technique, namely for full-screen presentations (though you still can’t hide the system’s own GUI). But there are a fair number of people on the Web who consider such meddling with the interface a “a slap in the face,” to quote ciwah once more. Perhaps such users aren’t in your market anyway, but you ought to at least understand their concerns. And if you don’t need the mess with the screen to best present your work, you really shouldn’t. Universal access is a noble goal, though paramount only if your content is also universal. As I’ve said before, the main trick to building site traffic is to avoid turning people off wherever possible. Or better, you should aim to make your design and content—if those are different—adapt to the viewing conditions, or at least degrade gracefully. There are other things you can do with a screen than fill it; you could, for example, dynamically adjust your content to fit the display or platform. That’s taking control in order to enhance access; it’s responding to the GUI, not messing with it. Even this kind of altruistic control will still anger the die-hard purists. If they had their way, we’d return to the days when <H1> really meant <H1>, JavaScript hadn’t been invented, and content (meaning “text”) was free of visual noise. (Indeed, the W3C has started rolling things back with XML and HTML 4.) In such a world, half of the Web as we know it couldn’t exist. In particular, graphic design, multimedia, and dynamic content would be impossible, whether users liked it or not. You couldn’t choose to view or avoid bad design, since design as such wouldn’t exist. And the result, in a purely platform-independent world, wouldn’t be more access, but less. – 30 – Originally published as part of my “Browser Window” column in InterActivity magazine (August, 1998) |
