While it is commonplace to criticize HTML, I’ve decided to summarize its drawbacks in my own words.

HTML has been created as a language for hyper-text, that is, a format for document representation. It was later misused as a language for web applications. But even as a document format, it has a number of issues.

Visual design is not separated from the content.

In HTML, you mix visuals and metainformation with information itself. With introduction of CSS, this issue has been mitigated, albeit not completely solved. HTML code is still organized in pages (i.e. in visual and navigational units) rather than in business domain entities.

Let’s take, for example, a web shop selling bikes. A bike has a name, description, manufacturer, price, image and tons of other technical attributes. In the web shop, clients won’t get all that attributes of a bike in a HTML file. Instead, what they get is a so called “detail page”, that is, a visual, containing a number of controls (navigation, footer, breadcrumb etc) all mixed together with bike attributes. Most typically, the bike attributes are not marked with typed tags, so that you cannot parse them back programmatically nor can you perform a search only in one kind of attribute, unless it is a specifically programmed feature of the server side.

Well, you could give types to the bike attributes using microformats.

But, clients still have to download, and then to strip away the navigation control and other visuals, every time they want to get bike attributes, which doesn’t really make sense. Why to make an entity description format from HTML that has been concepted as a markup of (mostly) untyped textual data? XML, and in particular RSS and Atom perform better as entity description formats.

Web apps also suffer from lack of this separation

Web applications have the usage pattern that is dramatically different from the original HTML intent: in a world of hypertext documents, you had downloaded a document (mostly one time), then read it, then saved or skipped it, and then navigated to another one.

With web apps, you download dynamic pages again and again in course of the interaction with the app. Because it is so hard to separate visuals from the content, all the visual markup and design may, depending on the implementation of the app, be downloaded every time interact with the app. 

This yields higher than neccessary traffic costs and also limits possible usage scenarios due to postbacks, that temporarily destroy user experience after each interaction.

Well, you can format the content in XML or JSON and load it using AJAX.

But then, you’ll get a number of problems: deeplinks, browser back button, favorites, SEO etc. And if not the whole your app is made using AJAX, you lose the continuous UI experience as soon as user navigates on to a different page. So, the question is, why still using HTML for UI rendering, if we pull the content in XML anyway and there are viable alternatives (Flash, Silverlight)?

HTML is poor internet application

The HTML-inherent “throw all that stuff in one document” paradigm plays a negative role also when we speak about interactivity.  To enable interactivity of web applications, an almost fixed (technically, it is very slowly expanding) set of tags had been defined as part of the HTML language, roughly corresponding to the state of the art at the time of their standardization. For example, in HTML 5 they going to add <audio> and <video> tags. Yawn…

Not only interactive controls are also transferred each time you load the page, resulting to traffic costs, but also, and more importantly, the fixed set of controls leads to limited usability.

In effect, HTML interactive controls represent the least common denominator of all or most used internet platforms over there. This wasn’t an issue back then in 1994-1995, when Netscape started to push e-commerce in Internet (they’ve introduced Javascript, SSL and cookies around this time), because a typical web shop looked like this: http://web.archive.org/web/19961219205128/http://www.pizzahut.com/

Well, you can try to sell the UI poverty as a virtue.

And then you get your share of purists and geeks browsing your site using an original ZX Spectrum or Commodore 64. 

People browsing your site on a 94 inch LCD need more twists and wizzles. So we need a client-side platform providing a very basic, but powerful, set of graphical and vector primitives and animations and thereby allowing to create “almost” any kind of UI as needed. And this is not the way HTML is or will ever be concepted.

(to be continued)