On WAP and Web: A matter of weight

One common statement from the WAP advocates (who, like the World War I veterans, are getting fewer by the year) is that WML is a more compact language than (X)HTML. Not so. It is a simpler language, you don’t need an as advanced browser to handle it, but the WML source is actually more bloated than HTML precisely because it is a simpler language. Since WML 1 doesn’t even have the headline elements (‘h1’ to ‘h6’), you can’t use code like <h2>A subhead</h2>, you have to do something like <big><big><b>A subhead</b></big></big>. Not only do you lose the useful information that “A subhead” is a headline, you need more markup to say less.

There are some byte optimisations, WML align=”c” is shorter than align=”center”, though using CSS would be even shorter than either of the two. HTML has some inefficient quirks, ‘strong’ and ‘b’ are used for the same purpose, and ‘s’ and ‘strike’ are two elements for the same visual effect. Sometimes old-style WML too use more verbose syntax, like <anchor>link text<go href=”url”></anchor> for <a href=”url”>link text</a>. More usefully WML has a compressed non-XML format confusingly called “binary XML” that gives considerable savings when the page is sent uncompressed from server to client. When sent compressed the gains would be minor.

The WAP graphics format WBMP is the only uncompressed format you will find on the web. Again designing for simplest possible processor doesn’t make for a compact format. The saving grace is that only black and white are allowed, WBMP images are supposed to be tiny, and that it doesn’t matter much if the data stream is compressed anyway.
Now, in the real world a WML page may be a few KB, while the source code for a news site like cnn.com might run into over a hundred, with the graphics clocking in hundreds more. Surely the WML page gives more news for the byte. Yes, it does, but that is not due to WML being a more compact format, but due to the WML page being crafted for small size. An equivalent HTML page will always be smaller, and an HTML+CSS page smaller still.
So why is the news page so huge? In a word: over-specification. If you look at the source code of a typical news page you will have a hard time finding the news items themselves for all the markup. Not only will you find the source filled with fonts and nested tables, the same effect is specified multiple times. Why is this so? Obviously the economics of serving and receiving web pages has not had a major role in the design. News sites have learned to serve simpler and smaller pages in times of major events where the surge of interest might overload the server, but when the crisis is over they return to the old design. The pages may be bloated, but they are tested and they generally look the same in every browser. Furthermore the code in some cases have passed the point of no return, they have grown so complex that any change will have unforeseen consequences. This particularly applies to JavaScript. Removing lines of script requires reading and understanding the existing body of code, adding even more lines does not. The script is now destined to continue growing until it collapses under its own weigth.

Join the Conversation

  1. Minimal XHTML Basic + CSS is what I think should be served to more small devices: you get all the power, its concise, it conveys meaning, a regular browser can grok it, and with something like opera SSR you don’t *have* to provide multiple and redundant copies of the same thing!

    If you use nested tables for design these days, your in my bad books: look, schmook, this the the dawn of the Semantic Web and we should be worried about how our pages get to our customers rather than how they look in the long run.
    Semantic meaning in markup, visual formatting in CSS, document behaviour in javascript/DOM. What the heck else do we need for xml/xhtml?

    SVG might be nice actually. SMIL. RDF. FOAF. RSS. Ok, we need a lot more.

    Don’t be a fashion nazi! Throw away tables! Empower small devices with XHTML basic.



Your email address will not be published.