Tales from the 90s: On XML’s Great Future, the Mobile Web on a 4×20-Character Screen, and Accessibility as the Original Responsive Design
by @frontenddogma@mas.to on , tagged history, standards, xml, sgml, html, xhtml, hdml, responsive-design, graceful-degradation, mobile, accessibility, user-experience (share this post, e.g., on Mastodon or on Bluesky)
The Frontend Dogma 1990s archive collects material from the Web’s first decade. Reading it today is more than nostalgia: Many of its entries argue about problems we’re still working on, and some got the answers right—just not always in the place they expected.
Here are three tales from the time: XML’s great future, a mobile Web designed for a 4×20-character screen, and accessibility guidance that anticipated responsive design.
XML’s Great Web Future: The Predictions That Were Right in the Wrong Place
The 1990s didn’t just give us HTML, CSS, and JavaScript. It gave us a very persuasive argument that XML would become the Web’s next universal language.
The argument is captured in motion: SGML primers in 1994 and 1997; early XML explanations; namespaces; XSL; arguments over tag sets; and, in 1998, a W3C working draft proposing to reformulate HTML as an XML application.
It’s tempting to retell this as a story of XML losing to HTML—but that misses what the period saw.
What XML Promised
The 1997 W3C overview, SGML, XML, and Structured Document Interchange, explains XML in refreshingly simple terms. HTML has a fixed set of tags; XML gives authors rules for defining markup languages of their own. The promise was not prettier angle brackets. It was a way to make data and documents legible to software without taking on all the complexity of SGML.
That promise was attractive:
- Documents could carry explicit structure rather than only appearance.
- Specialized fields could describe their own information.
- Processing and presentation could be separated.
- New device classes could use subsets or profiles appropriate to their capabilities.
- Systems could exchange data with fewer private formats and fewer guesses.
None of those ideas was foolish, as most are now ordinary parts of web development.
The Browser Was the Wrong Place for the Whole Victory
The 1998 HTML-in-XML draft is a great document because it shows the Web trying to solve two problems at once. First, browsers and platforms were becoming more diverse. Second, years of browser-specific HTML additions had made interoperability fragile.
Its proposed answer was modular HTML: Product designers could assemble standard building blocks—tables, lists, forms, images, and more—for particular device profiles. XML would provide a stricter foundation, while compatibility guidance would help existing HTML browsers participate.
The future it imagined did arrive, but in pieces and in different places. Structured formats, namespaces, schemas, feeds, configuration files, office documents, SVG, and many data-exchange systems made XML important. Separation of structure and presentation became a core web design principle. Devices did become heterogeneous.
What did not become universal was XML as the standard authoring and delivery syntax for everyday browser HTML. The Web retained its error-tolerant HTML parser, and the browser platform evolved around it. XHTML became a useful episode and a valuable source of discipline for some authors, not the replacement path the 1998 draft envisioned.
The Useful Way to Judge an Old Forecast
Calling this a failed prediction gives us little. A better question is: Which problem did the forecast identify, and where was the solution eventually adopted?
| 1990s Concern | What Endured |
|---|---|
| Data needs explicit, machine-readable structure | Structured data and domain-specific formats became normal infrastructure |
| Presentation should be separable from information | HTML and CSS reinforced the distinction, even when authors didn’t always follow it |
| Devices have different capabilities | Responsive design, progressive enhancement, and capability-aware delivery addressed this without requiring a different markup language for every device |
| Extension needs rules | The platform developed common extension mechanisms and interoperable standards, though not one unlimited “invent any tag” model |
This is why the archive’s XML Looks Like a Winner, but Where Are Its Tag Sets? remains such a good question. Extensibility is not useful simply because a language permits it—someone must agree on what an extension means, how it’s processed, and how it interoperates. The hard part was not putting a new name between angle brackets.
XML Was a Productive Detour
The XML era taught web developers to care about well-formedness, namespaces, transformations, modularity, and document structure. It also exposed the cost of treating strictness as a substitute for compatibility and of treating extensibility as a substitute for shared semantics.
The lasting lesson is not “never bet on a new format.” It’s that formats win where their trade-offs fit the job. XML was immensely useful where producers and consumers could agree on rules. The open Web needed something else as its common document language: a format browsers could process, recover, and evolve at enormous scale.
1990s articles on XML are worth reading because they preserve the uncertainty before that outcome became obvious. They show that the Web we have was not inevitable—and that several ideas we think of as modern were already being argued about, correctly, in what now looks like the wrong place.
The Mobile Web Was Invented for a 4×20-Character Screen
There’s another small time capsule with a large lesson: the 1997 Handheld Device Markup Language FAQ.
Its target devices had displays around four lines by 20 characters, limited CPU and memory, and connections of 9.6 kbps or less. That sounds almost too constrained to count as “the Web.” But its authors were not trying to squeeze a desktop page into a tiny rectangle. They were trying to make the Web’s infrastructure useful on a device that could barely display it.
That’s why the document remains more interesting than a list of obsolete tags.
“Just Make It Smaller” Was Already the Wrong Answer
The HDML FAQ asks why not use HTML, or simply a subset of it. Its answer is blunt: HTML’s navigation model relies on context that the smallest displays cannot supply. The goal, it says, is not to render every HTML page, but to use the Web to deliver data and content efficiently.
This is a useful correction to a common mobile-Web myth. Mobile design didn’t begin as an exercise in scaling down. From the start, it was an exercise in deciding what matters when space, bandwidth, input, and attention are all scarce.
HDML’s answer was a card-based interface with explicit navigation. A card could define what keys did; cards could be grouped into activities; history could be managed rather than simply inherited from a browser. The authors even warn about URLs with side effects: Going back and then forward again should not accidentally perform an operation twice.
That particular problem feels familiar to anyone who has designed a multi-step checkout, a confirmation flow, or a client-side application that has to coexist with “Back” and “Forward.”
Constraints Produced Good Questions
Some HDML answers are dated. Its limits were severe, its technology didn’t become the common web language, and modern phones are far more capable. But capability didn’t remove the questions it forced designers to ask:
- Can a person tell where they are and what comes next?
- Does the interface preserve enough context to make a choice safely?
- What happens if they revisit a URL or repeat an action?
- Which data needs to travel now, and which can wait?
- Can the task be completed with low bandwidth, limited input, and little screen space?
These are interaction-design questions, not merely device questions. A phone with a high-resolution screen still has a small attention budget. A fast network still has failures. A responsive layout can fit the viewport and still bury the next step, repeat a purchase, or send an unnecessary megabyte.
The Archive Shows the Fork in the Road
Consider HDML alongside articles on Compact HTML for Small Information Appliances, WAP, and graceful degradation of scalable internet services. They document a period when “mobile Web” could have meant several incompatible languages, device-specific profiles, or a more adaptable HTML.
The winning path was not a single perfect markup language. It was a web platform that increasingly made it possible to adapt HTML, CSS, and JavaScript to different capabilities. That outcome is easy to take for granted—the discarded paths show why it mattered.
HDML’s deeper contribution was its refusal to confuse access to the Web with access to a desktop page. A person holding a tiny device didn’t need every decoration and every column preserved. They needed a useful path through a task.
A Small-Screen Review for Modern Work
There is a practical way to use this history. Take a current mobile flow and inspect it as if the device had four lines, a slow connection, and a directional keypad. (Not literally, of course.) Use the thought experiment to ask:
- Is the next action obvious without seeing the entire page?
- Is the flow still safe when network requests are repeated or delayed?
- Is the important content available before optional enhancement and decoration?
- Does the navigation make a promise that Back and Forward can keep?
If that sounds like a harsh test, so was a 4×20 screen. The early mobile Web didn’t solve the whole problem, but it identified one enduring truth: Reduced space does not excuse reduced care.
Accessibility Was the Original Responsive Design
Responsive design has a date, a name, and a familiar origin story. But the underlying web design problem is much older: How do we make one document useful when readers have different software, devices, connections, senses, and ways of interacting with it?
Here, too, looking at past coverage is useful not as a nostalgia cabinet, but as evidence. Follow its accessibility, CSS, browser support, and mobile entries in date order, and a pattern appears: Work that we now separate into accessibility, responsive design, progressive enhancement, and performance was often treated as one problem.
The Document Was Never Just a Screen
In 1996, the W3C published Style Sheets for Producing Spoken Renderings. Its design philosophy didn’t assume that sound was a second-rate rendering of a visual page—it argued for separate visual and aural views of a document. That distinction matters: When the document has meaningful structure, different user agents can make something appropriate from it.
This was not a prediction that every site would soon have a bespoke voice design, but it was an argument about responsibility. Authors should describe content and meaning; a browser or assistive technology should be able to present that meaning in a form useful to its user.
The same thread runs through 1997 Using Standard HTML, 1998 Unified Web Site Accessibility Guidelines, and 1999 Web Content Accessibility Guidelines 1.0. The latter explicitly says that accessibility guidance also helps people using desktop browsers, voice browsers, mobile phones, and constrained environments.
That’s a much wider idea of a user than the one implied by a desktop mockup.
“Graceful Transformation” Is the Important Phrase
WCAG 1.0 calls one of its central themes “graceful transformation.” Pages should continue to work if a person cannot see or hear, has no mouse, has a small or monochrome screen, uses text or voice output, or has a slow connection.
That one principle explains a surprising number of recommendations that can otherwise look unrelated:
- Use structural markup and style sheets instead of presentation markup.
- Supply text equivalents for non-text content.
- Use relative rather than absolute units where appropriate.
- Keep navigation understandable without visual clues.
- Make forms, tables, scripts, and newer technologies transform rather than disappear.
None of this means that the designers of 1999 invented modern responsive CSS. Media queries and flexible layout systems changed how we implement responsive layouts. The more useful claim is that they had already identified the underlying condition: The author doesn’t control the reader’s environment.
The Shared Enemy Was Assumption
Looking at the archive makes the connection especially plain when its accessibility material sits next to entries on Best Viewed With Any Browser, graceful degradation, liquid design, caching, and small information appliances. Different constraints, same bad habit: treating one browser, one connection, one input method, and one display as normal.
Today we might call the remedies semantic HTML, progressive enhancement, responsive design, resilience, or inclusive design. The labels are useful, but they can make the work seem more fragmented than it is. A robust page is usually more accessible; an accessible page often survives more devices and conditions; a page that works with less JavaScript and fewer bytes usually gives more people a chance to use it.
What to Take From 1999
The lesson is not to canonize the 1990s. The period also produced plenty of browser-specific hacks, layout tables, frames, and technology churn. It’s to notice that the best guidance of the time was already resisting those pressures.
When we decide whether a design may rely on hover, a precise viewport width, a fast connection, a current browser, a pointer, or an image being visible, we are working on the same problem. Calling it responsive design is fine. Remembering that it has always also been accessibility is better.
(Parts of this article were edited with the help of AI.)