Seduced by Markup

The power of a technology now taken for granted

A friend wanted to show me a great new thing in 1993, this crazy HTML browser called Cello. He knew I was working on hypertext and this seemed like just the thing for it! Sadly, my time in HyperCard and an unfortunate encounter with the HyTime specifications meant that I bounced off of it, because markup couldn’t possibly work.

I was, of course, very very wrong.

Markup with some brilliantly minimal hypertext options was about to launch the World Wide Web. The toolset was approachable, easy to apply to many kinds of information, and laid the foundation for greater things to come.

In the early days of HTML it became clear pretty quickly that there were sane and insane ways to use markup. Some approaches, praised or sometimes mocked as “semantic” approaches, made it much simpler to apply Cascading Style Sheets (CSS) to documents, and manipulate their structure and content with JavaScript. Even when I was first writing about Dynamic HTML, starting from a clean document made everything so much easier. (XHTML got traction among at least part of the Web community for just those kinds of reasons.)

When I first got to XML, the markup was still primary and the processing an afterthought. Get the markup right, for many different values of right, of course, and the processing will be manageable. The markup approach offers some powers that I haven’t found in other data models and systems:

  • The very term “markup” reminds us that we are indeed ‘marking up’ documents that may have cohesive value on their own, not just as shredded and codified chunks of data.
  • Broken and incomplete documents may yet contain especially important information.
  • Markup leaves the door open for information that didn’t fit in someone’s prized model, allowing for format evolution rather than cycles of standardization. The structure of a given document is almost always easier to change than the programs that process it. (The nodes view emphasizes the priority of programs and all too often celebrates the things that make them brittle.)
  • Markup makes comprehensible possibilities that can’t be reached if you lock yourself into nodes from the beginning, like overlapping structures. Programmers indoctrinated into neat structure often see this as an utter corner case, but those who work with human documents know it exists regularly in the wild.

At some point, maybe around the time of the Microsoft “he doesn’t know what XML is” advertisement, a lot of people arrived in markup who had no interest in its details.

XML was exciting because it made clear that data interchange was possible with much simpler tools than its predecessors. Markup was still incredibly useful, but as the servant of programmers. XML structures suddenly had to look like programming structures, because nothing else could be trusted. They could look a little different, because after all programmers from different environments had different expectations, and there were documents to tolerate, but Schemas and WSDL and similar structured approaches dominated.

More recently, the rise of web applications has brought a similar challenge to the HTML side of the markup story. Single-page apps often carry a tiny bit of markup that launches a JavaScript program, which then sets about creating an abstract vision of HTML elements in the DOM. Instead of layering their code on top of markup, the code takes over, and the HTML lingers only as a readable serialization.

The data hygiene and mental hygiene of programming are not appropriate for markup. Programming and markup have connections, much like carpentry and plumbing, but their best practices are very different.

JSON, ASN.1, and similar approaches are much better fits for programming, which need only the structure but not the weight of markup. Over time, they (JSON in particular) are eroding XML’s share of markets it was never well-suited for anyway.

On the HTML side, I see some return to an appreciation of the value of markup. Content-first approaches to responsive web design can take advantage of the concrete nature of markup as a foundation for CSS but also its flexibility—’sketching’ in markup isn’t that hard. Hopefully Web Components will make it much easier in the near future, letting many more people enrich the HTML markup vocabulary with minimal disruption. Even on the more programming-centric side, I see this piece on Isomorphic JavaScript suggesting a path forward that at least exposes more HTML on the Web rather than hiding information beyond JavaScript and APIs.

Markup isn’t done yet.

Related

Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Platform