Recently the Twitter Bootstrap documentation gave a name to something that I've been excited about for a pretty long time: Markup API.
Markup APIs give superpowers to HTML.
Through the use of class attributes, data attributes, X-Tags, or other conventions they effectively extend the behavior of HTML, turning it into a kind of magic ink. Favorite examples of mine include Twitter Bootstrap, Wowhead Tooltips, and my own Instapoppin.
The advantages of a markup API over a JavaScript API are numerous:
- They mean that an author only needs to know HTML, whose syntax is very easy to learn, rather than JavaScript, whose syntax is comparatively difficult to learn.
- Because the API is in HTML rather than JavaScript, it's declarative rather than imperative. This makes it much easier for development tools to intuit what a user is trying to do—by virtue of a user specifying what they want rather than how to do it. And when a development tool has a clearer idea of what the user wants, it can offer more useful context-sensitive help or error messaging.
- Because of HTML's simple and declarative structure, it's easy for tools to modify hand-written HTML, especially with a library like Slowparse, which help ensure that whitespace and other formatting is preserved. Doing the same with JavaScript, while possible with libraries like esprima, can be difficult because the language is so complex and dynamic.
These advantages make it possible to create GUI affordances atop hand-coded HTML that make it much easier to write. As an example of this, I hacked up prototype slideshow demo and physics demo in July of last year. Dragging an element with the class thimble-movable in the preview pane changes (or adds) CSS absolute positioning properties in the source code pane in real-time, and holding down the shift key modifies width and height. This allows users to size and position elements in a way that even a professional developer would find far more preferable to the usual "guess a number and see how it looks" method. Yet this mechanism still places primacy on the original source code; the GUI is simply a humane interface to change it.
This is the reverse of most authoring tools with an "export to HTML" feature, whereby an opaque internal data model is compiled into a blob of HTML, CSS, and JavaScript that can't be re-imported into the authoring tool. Pedagogically, this is unfortunate because it means that there's a high cost to ever leaving the authoring tool—effectively making the authoring tool its own kind of "walled garden". Such applications could greatly facilitate the learning of HTML and CSS by defining a markup API for their content and allowing end-users to effortlessly switch between hand-coding HTML/CSS and using a graphical user interface that does it for them.