WAP and the Mobile Web: The First Attempt at Browsing on Phones

In 1999, mobile internet was a live commercial product. Phones could browse the web. It was slow, expensive, and the content was largely useless — but it worked. WAP (Wireless Application Protocol) was the standard that made it possible, and at Motorola we shipped phones that implemented it.

I was on the mobile software team during the WAP deployment. This is what the technology actually looked like.

What WAP Was

WAP was a protocol stack designed for the constraints of mobile networks in 1999:

Bandwidth of 9.6 kbps on GSM CSD (circuit-switched data)
Latency of 5–15 seconds per round trip
Screen sizes of 96×65 pixels
8-bit processors with 4–8 KB of heap

You could not run HTTP over this. HTML pages, even simple ones, were too large. WAP replaced HTTP with a binary-encoded protocol stack and replaced HTML with WML (Wireless Markup Language).

WML: HTML's Constrained Cousin

WML was XML-based and structured around cards grouped into decks. A deck was a single file. A card was a screen. The user navigated between cards with <a> links or <do> actions.

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
    "http://www.wapforum.org/DTD/wml_1.1.xml">

<wml>
  <card id="home" title="Motorola NMS">
    <p>
      Network Status<br/>
      <a href="#status">View Devices</a><br/>
      <a href="#alerts">Active Alerts</a>
    </p>
  </card>

  <card id="status" title="Devices">
    <p>
      Router-01: <b>UP</b><br/>
      Switch-02: <b>UP</b><br/>
      Hub-03: <em>DOWN</em>
    </p>
    <do type="prev" label="Back">
      <prev/>
    </do>
  </card>

  <card id="alerts" title="Alerts">
    <p>
      2 active alerts<br/>
      <a href="alerts.wml">Details</a>
    </p>
    <do type="prev" label="Back">
      <prev/>
    </do>
  </card>
</wml>

WML had no CSS, no JavaScript (WMLScript was a separate feature), no images beyond tiny 1-bit icons. Layout was handled with <br/> and <p>. Tables existed but were rarely rendered correctly across handsets.

WMLScript: Logic on the Client

WMLScript was a stripped-down ECMAScript variant that ran on the handset. It handled form validation and simple UI logic without a network round trip:

extern function validateLogin(fields) {
  var username = WMLBrowser.getVar("username");
  var password = WMLBrowser.getVar("password");

  if (String.length(username) == 0) {
    WMLBrowser.setVar("error", "Username required");
    WMLBrowser.go("login.wml#loginCard");
    return;
  }

  if (String.length(password) < 4) {
    WMLBrowser.setVar("error", "Password too short");
    WMLBrowser.go("login.wml#loginCard");
    return;
  }

  WMLBrowser.go("authenticate.wml");
}

On a 9.6 kbps connection, client-side validation was not a convenience — it was essential. A round trip to the server for a validation error could take 30 seconds.

The WAP Gateway

WAP clients did not connect directly to web servers. Traffic went through a WAP gateway operated by the carrier:

Phone ──[WAP/WSP]──▶ Carrier Gateway ──[HTTP]──▶ Web Server
                     │
                     │ Converts WAP binary protocol to HTTP
                     │ Compresses/decompresses content
                     │ Transcodes WML ↔ WBXML (binary WML)

The gateway was simultaneously the most important part of the stack and its biggest weakness. It sat in the middle of every request. Carrier gateways were unreliable, slow, and sometimes cached responses incorrectly.

Why WAP Failed

The gateway model was broken. Every carrier ran their own gateway with slightly different behaviour. Content had to be tested on each carrier's equipment. WML that rendered correctly on Vodafone's gateway looked wrong on T-Mobile's.

The user experience was genuinely bad. A single page load took 10–30 seconds over CSD. Most WAP content was operator portals with no useful services. The killer app never arrived.

GPRS arrived and changed everything. GPRS (2000–2001) replaced circuit-switched data with packet-switched data at speeds up to 171 kbps. With GPRS you could run HTTP directly. WAP Over TCP (WAP 2.0) was essentially just HTTP with a proxy. The WAP stack became unnecessary.

The iPhone finished it. Safari on iOS in 2007 showed that a mobile browser running full HTML/CSS was achievable. There was no longer any reason to maintain a parallel content ecosystem.

What WAP Got Right

The constraint-driven design of WML — cards, limited input, no assumptions about screen size — foreshadowed every mobile-first design framework that followed. The problems WAP was solving were real. The solutions were the best available at the time. When the constraints changed, the solutions were replaced.

That is how technology is supposed to work.