Animation and 3D: the web is doing it wrong

Published on 2013-10-10

Have you ever created a dynamic animation on a web site, or displayed a 3D object? Really, why is it so complicated? Why should I learn how to use half a dozen libraries, write dozens of line of boilerplate HTML, WebGL and CSS code, just to rotate some text on the screen or display a 3D object? Why do I need three (or four, or five) languages, libraries or frameworks to design a single animated web page?

We know how to fix it. Would you help us?

In the realm of business presentations, Tao Presentations solved this problem with a 3D dynamic document description language, letting you easily create sophisticated interactive 3D animations and presentations. What if we brought this very innovative platform to the web? What kind of applications would become possible if we improved web browsers in the areas of storytelling, interactivity, 3D or multimedia?

TL;DR: With Tao Presentations, we demonstrated what programmatic animation and 3D should look like. We need your help to bring that goodness to the web.

A document description language, how unoriginal is that?

Using a programming language to describe documents is not exactly a new idea by any measure. The scientific community, for example, relies on typesetting languages called TeX and LaTeX. For the printed page, Postscript and its simple-minded descendant PDF are de-facto standards. On the web, XML and HTML are the foundation of all web documents. All these languages are seriously old by computer science standards. The youngest one, HTML, was invented by Tim Berners-Lee in 1990, and Postscript was first released in 1982.

But TeX is even older. It proudly celebrated its 32nd birthday in 2010. Thirty two years, as in "100000 in binary". One hundred thousand years turns out to be a pretty good approximation of what 32 years old software feels like in the software industry. Just think about it: TeX was initially released in 1978, a full three years before MS-DOS 1.0! Even the 8-bit Apple II+, the first Apple II with a BASIC written by Microsoft in it, is not as old as TeX.

pastedGraphic.pdfSo TeX should be long dead of old age and bit rot. Yet it’s not just alive, it’s thriving. LaTeX remains the defacto standard in the scientific community today, says Wikipedia. The graph on the side, courtesy Marko Pinteric, gives one plausible explanation for this longevity: LaTeX is powerful. So powerful, actually, that even after more than thirty two years, it runs circles around Microsoft Word for any sophisticated writing task.

For those allergic to fancy graphics, Pinteric provides a nice textual explanation of what this extra power really means:

Although Word is a useful and practical tool for writing short and (very) simple documents, it becomes too complex or even unusable when one wants the word processor to do more complicated tasks. [...] LaTeX does require more effort and time to learn to use even for simpler tasks, but once learned, difficult tasks can be accomplished rather easily and straightforwardly. Therefore, LaTeX is simpler, faster and better way to produce large or complex documents and the additional effort eventually pays off.

Tao Presentations uses a document description based on a programming language for the exact same reason. A tool built around a language is more powerful. It makes it possible and even easy to create presentation documents that run circles around all other presentation tools. Try making sense of one billion data points with Powerpoint’s charting tools… Try showcasing a 3D model with what Prezi calls 3D… Tao Presentation can show very large data sets, integrate and animate all kinds of 3D objects, and if you want to connect to the web to show the latest news, you can do that too.

A description language designed for real-time interactive 3D

Following TeX, Postscript or HTML, Tao stands on the shoulders of giants. But it brings three massive improvements over its illustrious predecessors:

  1. additional visual impact, in particular thanks to the third dimension,
  2. interactivity, thanks to real-time rendering and event handling,
  3. a focus on storytelling thanks to a customizable syntax that lets you write readable code.

The following example illustrates these three points. In a few lines of code, it shows a slide containing a dynamic clock in 3D. You may try it by downloading Tao Presentations, pasting the code in a file called for example slide.ddd, and then opening that file with Tao Presentations. The .ddd extension stands for "dynamic document description" as well as "3d", and these are two of the three good reasons we had to pick it as the usual extension for Tao Presentations documents.

First 3D slide

import Slides
slide "My first 3D slide",
    * "This uses a simple language"
    * "Yet you can do complex things: "

show_time ->
    light 0
    light_position 1000, 1000, 1000
    rotate_y -30 - 20*sin time
    rotate_x 0.3 * mouse_y
    extrude_depth 20
    color "red"
    font "Ubuntu", 120
    text zero hours; text ":"; text zero minutes; text ":"; text zero seconds

zero N ->
    if N < 10 then "0" & text N else text N

This little program is enough to illustrate the three key points I talked about, visual impact, interactivity and storytelling:

  • The slide draws a clock in 3D red text, which rotates over time in a smooth animation. In order to avoid being killed by large beasts, human developed an acute attention to what moves, so simple animations like this can be used to catch the eye. Even better, having a true 3D scene description means that your little slide now automatically translates to eye-popping 3D on any 3D TV. Now you can take full advantage of another evolutionary trait of human beings, their not-so-irrational belief that "what is close matters". With no additional effort on your part. How cool is that?
  • The document automatically reacts to mouse movements, simply because there is a reference to mouse_y somewhere in the program. So if you move the mouse up and down, the text rotates up and down as well. Building simple animations that react to your actions is a good way to give life to your slides. And see how easy it is? You simply add a rotation that depends on the mouse, and automatically, Tao figures out for you how to react to mouse events. Again, without any significant effort on your part. Double-plus über-goodness here.
  • This document description is short and uses readable notations that connect with our intuitive understanding, i.e. a "slide" or a "bullet point". This is one important aspect of storytelling. The set of notations you can use in Tao is not fixed as it is in HTML. Here, we add two notations, one for show_time and one for zero N. Tao can be extended to tell your story using higher-level concepts, just like human languages in real life, or… like HTML6. If you believe that this is just a boring function definition and that there’s really nothing really exciting going on here, you are almost completely wrong, as we shall see below in section "The Play-Doh of Programming Languages".

Digression: the web site about HTML6 wets your appetite with "Imagine writing <month>this</month>" before explaining that you really will have to replace <img foo> with <html:media type="img">. A definite non-improvement, that. And the technique of announcing one thing and delivering another is called bait switching, folks. As we shall see, with Tao you can call a month a month.

Seriously, why invent a new language?

The document description language in Tao Presentations derives from a little-known open-source language called XL. These initials stand for "eXtensible Language". To quickly wrap your mind around XL, you can think of it as XML without the M, i.e. an extensible language without markup. You can also think of it as a Lisp without the parentheses, i.e. a very simple homoiconic language deriving its power from metaprogramming. Gesundheit. Don’t Panic™, if you don’t know what this jargon means, I’m going to explain it below.

But more importantly, XL is simple. Real simple. As in: the core language has one operator. Not two, one.

The Play-Doh of Programming Languages

XL was originally designed as an extensible programming language, i.e. one where it would be just as easy to add a new notation or a new feature as it is to add new classes in an object-oriented language.

For example, say that you want to add an if-then-else notation. In XL, you would write the following definitions, where -> reads as transforms into:

if true  then X else Y  -> X
if false then X else Y  -> Y

What this code means is that if true then X else Y transforms into X, X being a variable that can be replaced with anything. This is what "homoiconic" means: code is data and can be manipulated as data. Similarly, the sequence if false then X else Y transforms into Y.

With these definitions, you can now use if-then-else as you would in other languages. For example, you can write stuff like:

if X > 0 then
    color "red"
    color "blue"

or in a more compact form:

color (if X > 0 then "red" else "blue")

The definitions above happen to be almost exactly the ones that you can find in the XL standard library. Now, what you have just done is add a new notation, specific to a particular need. The tool we just used is more powerful than mere functions or classes, because it lets me define exactly what my programs will look like. This is internally how XL defines what A+B should do, for example. But it’s not operator overloading either, because you could as well define what A+B*C does.

This is also the mechanism used to define slide or bullet points, leading to the kind of "markdown" language we used in the first example. Except that, you now know, this is not a markdown at all, but simply "function calls" (or macros, or whatever you want to call them):

slide "My first 3D slide",
    * "This uses a simple language"
    * "Yet you can do complex things: "

And it’s also obviously the same tool we used to define show_time or zero in the very first example we gave at the beginning of this article:

zero N ->
    if N < 10 then "0" & text N else text N

Conclusion: XL (and consequently Tao) lets you define your own notations in programs. This is called concept programming.

One operator to rule them all. It’s spelled -> and reads "transforms into".

The definition of if-then-else uses the one and only operator we were referring to above. It is spelled ->, is called the rewrite operator, and reads "transforms into". So the first of the two lines above reads as "if true then X else Y transforms into X". Neat, eh? The good news is that now, you practically know all there is to know about XL. The rest is in the libraries, some of which are implemented as XL code, some of which are implemented in C++ using a specific interface.

Of course, knowing a few implementations details matters. And you need to learn a bit about what you can find in the libraries, or how to write new ones, before you can become productive with XL. And there, get prepared, as there’s a lot to learn. But conceptually at least, all of XL derives from this single rewrite operator. So the first rule to remember is that in XL, A->B means that you should transform A into B.

Based on what you already know, can you guess how you declare a variable in XL? Bingo, you use the very same rewrite operator:

X -> 0

With this declaration, X transforms into 0, therefore any use of X is equivalent to using 0. But there’s a major benefit: now you can change the value of X with something like X:=1, and all uses of X will see the new value.

A note to C / C++ / JavaScript / PHP programmers: XL arbitrarily uses = to mean "equal", and := to mean "assign". Other languages use = to mean "assign" and == to mean "equal". More recent languages have === and possibly ========= (I'm not positive on that one). That, sir, is called progress. Boink.

Well, the choice of assignment operator in XL is merely an indication of how old the language designer is. Young people, please learn this: there once was a time when Pascal, not C, ruled the world. And the early design of XL predates the time when C (let alone C++, Java, JavaScript and all these newfangled { } idioms) ruined everyone’s taste. <trollbait>Pascal and Ada were elegant, Pascal and Ada were actually designed.</trollbait>.

The choice of using = for equality, however, highlights a concept programming rule, namely that code should look like the underlying concept. In that case, mathematical equality is written using an equal sign, so XL uses an equal sign.

You can use arbitrary Unicode characters in variable names, so it is perfectly legitimate to write π->3.14, at least if you don’t care much about the precise value of π. Of course, you can then assign an entirely different value to π, but it’s considered bad taste, a bit like assigning another value to 0.

Conclusion: XL is a language based entirely on rewriting (specifically, for the technically inclined, parse tree rewriting), where you say how one notation transforms into another.

Homoiconic document descriptions make all your documents dynamic

For those unfamiliar with web programming, the core idea that lets JavaScript manipulate HTML documents is called the Document Object Model (or DOM). It is a standard way for JavaScript to access the internal structure of the document programmatically. That way, the JavaScript code can read the document, update internal values, and more. This is powerful, but I will argue that the designers of the DOM gave us a clumsy tool. Why? Mostly because they, willfully or not, ignored decades of research about metaprogramming and homoiconic languages in the Lisp community.

It’s hard to entirely blame them for that. Words like "metaprogramming" and "homoiconic" are up there on the jargon scale, along with "unicuspid", "metempsychosis", "catabolism" or "postprandial" (darn, now I feel some kind of stupid moral obligation to use each and every one of these words in this article). Besides, the Lisp community has a well-deserved reputation for being intimidating. But really, it's nothing meta, it's just programming with programs as the data, and that's pretty darn efficient.

So let me explain the relationship between these words and the DOM. The word "homoiconic" describes a programming language in which the program itself is a form of data. In Lisp, for example, (+ 1 2) is a short program that computes the addition of 1 and 2. But it is also a list composed of 3 elements, +, 1 and 2. So you can build such a list programmatically, evaluate that list, and the program described by that list will behave exactly as if you had typed it yourself. Conversely, you can build an evaluator for this program in Lisp, and it can behave like the original evaluator in Lisp. Or entirely differently. You get to choose.

Why does metaprogramming matter for documents? Well, consider the following fragment of an HTML document:

<h1>HTML is not a programming language</h1>
<p>You can’t compute anything with HTML.</p>

In a homoiconic language like XL, you can represent this same document as "data", with something like:

h1 "HTML is not a programming language"
p "You can’t compute anything with HTML"

or in Lisp style:

(h1 "HTML is not a programming language")
(p "You can’t compute anything with HTML")

The difference in notation at this stage is relatively minor. The difference in semantics, however, is huge. Because now you have an entire programming language at your disposal, so you can easily create dynamic documents, add computations, perform tests. We used that in our document when we added a clock:

text zero hours; text ":"; text zero minutes; text ":"; text zero seconds

This will produce something like 17:03:45, where the time being shown is the actual, current time!

Conclusion: Describing documents with a homoiconic language lets you use natural notations for standard document structure, all with the power of a true programming language.

The Tao of dynamic documents

The name Tao Presentations was chosen for two reasons. One, T.A.O. stands for The Art Of. The art of presentations is our business. But in the eastern philosophy, the Tao is also the right way to do things. And indeed, using a real, extensible programming language to describe dynamic documents is The Right Thing™.

Don't repeat yourself (or why DOM means "Describe Once More")

Let’s first consider homoiconicity. What is the big deal with considering code as data? Why does it matter for describing dynamic documents? In HTML, the DOM is data only. So if you need a piece of code to manipulate it, it needs to have a way to reference it. In the case of HTML, this is done using a special name called an id. For example, your HTML document contains:

<div id="my-special-name">Hello World</div>

Now the given div element has an id, my-special-name, that is supposed to identify it. So it must be unique. Don’t reuse it for anything else in the document, it’s bad. Also, don’t forget this id, you’ll need it later, in a completely different piece of code that manipulates the DOM:

var element=document.getElementById("my-special-name")

Having to remember an id like this may seem easy enough. But in the real world, you have dozens of interacting pieces of code, many of which you did not write yourself, and that simple problem becomes "interesting". And it leads to subtle issues: who can tell, on the top of their head, what happens if the same id is used multiple times in an HTML document?

The only reason you need to connect the code and the data that way is because you assumed that the code and the data are distinct entities. Therefore, you need a bridge between them. You cannot specify things all in the same place, which leads to unnecessary code, which is… I’m looking for the right word. Ah, yes, it’s bad. (And no, I'm not saying that separation of concerns is a bad thing, just that it's a matter of code organization, not something that should be enforced by separate languages).

But if you take the approach that code is data and data is code, then any dynamic part of the document can be simply placed in-line in the document, using the same language already used to describe the document. Rendering the document will follow the evaluation rules for the language, and voilà, It Just Works™! No silly names to identify pieces of the document. No need to think about unique ids all the time. No unnecessary complication. This is… good, you got it.

Conclusion: Considering that data and code are the same thing (homoiconicity) enables a much simpler document structure and gets rid of a lot of duplication.

Unicuspids vs. Quotes, pick your poison

In reality, there is a minor complication. Let’s consider the syntax of Tao, as opposed the the syntax of a markup language. One might fear that the syntax of a programming language will not be very adequate for structured documents. That primitive, almost reptilian fear, is almost totally unfounded.

In HTML, anything that is not a tag (i.e. not between brackets) is being shown. For example, if you want to display "Hello World" in a paragraph, you would write:

<p>Hello World</p>

In HTML, there are a few, rare exceptions to the rule that text outside of tags will be shown. We already saw one example with the <canvas> element:

<canvas>This text shows if your browser does not support canvas</canvas>

Text inside a <canvas> only shows if your browser does not support canvas. But, again this is an exception. In a data-oriented language like HTML, the default for text is to represent contents, and you have to "escape" text that you don’t want to show. In HTML, this escape mechanism uses unicuspid < and > characters, so-called "angle brackets". For example, the <p> tag indicates a paragraph. If your web browser shows the sequence <p> on screen, it is not very compliant with the HTML standard…

This HTML syntax is optimized under the assumption that an average document mostly contains text. That assumption is totally wrong these days. To prove it, I did a simple experiment that I invite you to repeat on web pages of your choice. I took a Google search result page, which looks like mostly text to the average layman. I copied the source code of that page in one text file, and the page text in another (i.e. I copied the whole page and pasted it in Emacs). In my experiment, I got 114124 characters for the source code, and 3369 characters for the text.

In other words, the visible text represents less than 3% of the source code of the Google results page! And that’s with HTML code that Google is careful to heavily pack using automated tools. Code that is readable by humans would tip the balance even further away from textual contents. In retrospect, it seems like a good idea to optimize the syntax for the 97% of non-text rather than for the 3% of text.

This is the approach in Tao. By contrast to HTML, text in Tao is only one of the possible forms of data. You need to specify where the text is, and you need to say what happens to it. A paragraph in Tao would be represented for example with:

paragraph "Hello World"

You need to surround the actual text with quotes, but then you don’t need to escape tags. Even if we stick to a silly metric like counting characters (related to more significant metrics, like number of damaged carpal tunnels per million documents typed, or watts per trillion useful characters), this is a net win. In the Hello World case, the number of "useless" characters in Tao is two (the quotes); the number of useless characters in HTML is five (four unicuspids and a slash).

Of course, one might object that paragraph is longer than p, to which I would respond with the one and only rewrite operator, accompanied with a loud ta-dah:

p X -> paragraph X
p "Hello World"

An additional benefit of this approach is that you can perform computations on text, like concatenating text with the & operator. This is necessary if you want to compute part of the text dynamically:

paragraph "Hello " & "World " & text seconds

And by the way, "unicuspid": check.

Conclusion: The syntax in Tao is optimized for what matters in modern documents, the structure and the dynamic code. It leads to less typing and simpler source code.

Metempsychotic HTML

The structure of documents is one aspect where markup languages might appear superior to programming languages. At least, they might appear superior to the young, naive and uninitiated padawan. Let’s debunk that belief.

The heart and soul of markup languages such as HTML is the idea that documents have a hierarchical structure. For example, inside a paragraph, there may be a section that is written in italics, and inside that section, a part of the text is written in bold and another part is in red and underlined. This would render as something like: This is not recommended at all.

With HTML, you might be tempted to write it as follows:

<p>This <i>is <b>not</b> <color "red"><u>recommended</u></color></i> at all.</p>

Well, actually, that would not work, because for some reason that always eluded me, HTML has a <u> tag for underline, even a <blink> tag for blinking text, but it has no <color> tag. "Illogical", sez Spock. It almost seems like the web was invented on a black-and-white computer. Ah, but wait, it was.

Whatever the reason is, in actual HTML, what you really need to write is a little bit more convoluted:

<p>This <i>is <b>not</b>
   <span style="color:red"><u>recommended</u></span></i>

But hey, what’s a few extra characters, your carpal tunnel syndrom is not that advanced yet, stop complaining.

As an aside, this little fragment of code allows us to discover Yet Another Web Language (YAWL) called CSS, which stands for Cascaded Style Sheets, whatever that means. The CSS portion in our example is discretely encapsulated in quotes, in the small fragment style="color:red". So yes, you need quotes as well in HTML. But don’t worry, there are at least half a couple other ways to mix CSS and HTML, including in <style> tags or in separate files introduced with the <link> tag. As usual, a "standard" means that there is no standard way to do things.

We can expand that same fragment of code a little bit to make its hierarchical structure apparent:

    <span style="color:red">
 at all.

This kind of hierarchical structure is the heart and soul of HTML and of other markup languages such as XML or SGML. This is the soul we are going to transfer in Tao, as follows:

   text "This "
       text "is "
           text "not "
       color "red"
       underline "recommended"
   text " at all"

This form can be called metempsychotic HTML, in that it transposes the basic structure of HTML, although the tags are written in a different way. The hierarchy remains the same.

"Metempsychotic": check.

Conclusion: Tao uses a real programming language, but it is possible to transpose HTML document structures directly, in a very simple way.

Catabolism of complex document structures

Despite the apparent similarity in structure, what happens under the hood is entirely different between HTML and Tao. Markup languages and programming languages differ in their semantics, i.e. the way you interpret or "evaluate" the code.

In the case of HTML, the browser renders tags in a pre-determined way. You can change the way a tag is rendered using "styles", but that’s about it. In the case of Tao, rendering a document boils down to evaluating the program, using the normal rules of the XL programming language, following the definitions given by the rewrite operator. This mechanism breaks down the more complex code structures into simpler ones, recursively, until we reach "primitive" operations that directly draw something on screen.

The Tao implementations of paragraph or italic can be found in the tao.xl file, located in the application directory. If you are curious, you can see what it looks like on-line. Here is for example the implementation of italic and bold:

italic Body ->
        render Body
bold Body ->
        render Body

In turn, render is implemented as follows:

render Body:block -> do Body
render T:text     -> text T

Now, we can break down a hierarchical structure into simpler elements, one step at a time:

italic { bold "Hello" }

To evaluate this code, the following sequence happens:

  1. We first call italic with a block argument { bold "Hello" }.
  2. Per the definition of italic Body, this creates a text_span, selects italic text, and then evaluates render Body.
  3. In that case, Body is the block { bold "Hello" }, so we select the first implementation of render.
  4. We now evaluate the block { bold "Hello" } given as an argument to render, calling bold Body.
  5. We create another text_span, select bold text, and then evaluates render with "Hello" as an argument.
  6. This time, we use the second implementation of render, and draw the text.

The mechanism terminates when we reach primitive operations, i.e. operations that are implemented directly in C++ in the Tao rendering engine or in some extension module. For example text_span is a primitive operation in the current implementation of Tao.

You can easily add your own tags this way. For example, important can specify a red color, bold and italic:

important Body ->
        color "red"
        render Body

These simple examples show how a complex hierarchical structure is automatically broken down into individual drawing primitives, by virtue of simply evaluating the program. Incredibly simple, incredibly flexible. Now, you can render tags the way you want.

"Catabolism": check.

Conclusion: Tao implements the document structure simply by evaluating normal "functions". You can add your own. Welcome to a world of open document structures.

Sometimes, the right word is "postprandial"

While the structure in Tao can be made similar to that of HTML, the details of the syntax in Tao are very flexible. For example, you can also render This is not recommended at all in a much more packed way, using curly braces to define blocks instead of indentation, semi-colons to separate statements instead of line breaks, and a few user-defined shortcuts:

p X -> paragraph X
i X -> italic X
b X -> bold X
u X -> underline X
$ X -> text X
p{$"This ";i{$"is ";b{$"not "};color"red";u"recommended"};$" at all"}

You can even replace curly braces with parentheses if you prefer Lisp style to C style. It Still Just Works™. Don’t get me wrong. This kind of style, while possible, is not recommended (think of "not recommended" as being written with a heavy dose of red, bold, underline, italic). But it illustrates the flexibility given by the one and only rewrite operator when transposing concept from HTML.

What is more important is that often, higher level structures will emerge in a document, and it is useful to give them appropriate names:

main_title_slide "Main title",
        text "Seasons Greetings theme"
        text "A theme for the Holidays"

With this approach, Tao offers the kind of high-level document structure found in LaTeX, and that you can only dream of in HTML. It is easy too, because our brains are wired with language. Using common words such as title requires absolutely no effort.

Learning the meaning of new words, such as postprandial isn’t very complicated. The reason I use this particular word as an example is because of the way we learned it at Taodyne. We used to have a walk after our lunch, during which we’d discuss technical and non-technical topics together. After a while, one of us started wondering if there was a word meaning "after lunch". And it turns out that there is one. So instead of talking of our walk after lunch, we started talking of our postprandial walk.

Up Goer FiveIt may seem like a minor shortcut. But this applies naturally to more complicated concepts. Of course, it is always possible to only use a restricted vocabulary, as illustrated by XKCD’s excellent up goer five comic. But who wants to do that?

Right now, HTML writers have not much choice. Documents in HTML tend to be expressed using such a dumbed down language, with a "vocabulary" of a few dozen words only:

<h1 class="main_title">Main title</h1>

Since we don’t use higher level words, even a concept as simple as a title ends up being split into two distinct aspects, its "level" <h1> and its "style" main_title. In the case of HTML, these two aspects even belong to different languages: headings such as <h1> are defined by HTML, whereas styles such as main_title refer to CSS styles. HTML is not only verbose but also highly schizophrenic. And if you want to extend HTML, as Reveal.js does for instance, you add a third party to the mix, namely the JavaScript library rewriting your HTML code on the fly.

By contrast, when I write main_title_slide in Tao Presentations, I make it quite clear that I intend this slide to represent a main title slide. How you implement main_title_slide is interesting, but what really matters is the ability to convey the intent. Being able to create your own version of main_title_slide is valuable, knowing that it will only impact main title slides is even better. Creating domain-specific languages for your domain of expertise is handy, but ultimately what you care about is to focus on the right level of expression when telling your story.

When you write your code, you should stop explaining what it does, as in "the walk we do after a meal". You code should really focus on a higher level, as in "the postprandial walk".

"Postprandial", check, and that concludes my silly experiment.

Conclusion: The ability to add new entries in our vocabulary is essential for brevity, clarify and structure. That ability is almost entirely lacking in HTML.

Yes, but… A few common objections

Now, before going on explaining how Tao Presentations operates, I need to address a few objections I heard often enough to mention them ahead of time.

Objection 0: But wait, it’s not ugly! (sometimes spelled "But wait, it’s ugly!")

Unreadable codeMany seasoned developers feel ill at ease the first time they read Tao Presentations documents. Don’t panic, it’s all right, it’s just that most of us have unwillingly been over-exposed to PLDTLLLN (Programming Languages Designed to Look Like Line Noise) and as a result fell prey to a rather bizarre form of punctuation addiction. If code does not contain a sufficient density of curly braces, angle brackets, or Lots of Insipid and Stupid Parentheses™, we feel completely lost.

This is largely the fault of programming language designers who insisted on using every single ASCII character there is in their language. We end up with programming languages that are all @ this, $ that and <glop> or [grunt] all over the place, when it’s not makefiles distinguishing between different forms of whitespaces (See page 184 of the Unix Haters Handbook for an interesting story about that particular design bug). All these mysterious characters turned programming into wizardry incomprehensible to mere mortals. Boy, d03$ it f33l g00d t0 b3 @n 3133t! Note that the trend of using every single character in the book may be fading out: I have yet to see a programming language that requires every single Unicode character in its syntax…

Anyhow, having::random(characters)->all[over].the+*place is not a good thing, people. Most of us speak english with a remarkably limited need for curly braces, angle brackets, arobases or ampersands. And if we happen to use symbols in writing, it’s generally more as a shortcut symbol for an operation, as in joe@home or 2+3. So why not just try and do the same in computer languages for a change? Frankly, what makes <h1> any better than title? And in the two following two lines, which one would you rather type, knowing that both will work in Tao? Don’t you care about your carpal tunnel?

color ("red");
color "red"

Conclusion: Tao limits the use of bizarre symbols on purpose, and good riddance.

Objection 3.14: nothing new here, web pages are already dynamic

Earlier document description languages such as TeX, PostScript and HTML, have been designed for the printed page. Since e-Ink was not all the rage 30 years ago, the contents of printed pages did not evolve frantically after it had been printed. Cheap paper would slowly turn yellow, cheap ink would slowly fade, but that was about all the animation you could get. So the need for animations in a page description language was not entirely obvious back then.

Under constructionNow, after visiting hundreds of fancy web sites, you might think that HTML is a super dynamic language. You could not be more wrong. HTML, all by itself, is pretty much useless as far as animations are concerned. Granted, you have the dreaded and luckily obsolete <blink> tag, that could be used to make ugly web pages look much worse. And you have animated GIFs, most of them used to show silly under construction signs. But that is about it. In short, nothing worth sacrificing kittens to.

The root cause of this paucity in animation-fu is that HTML is a declarative language, which is technical jargon for "about as capable of doing general computations as a jar of overcooked broccoli". Or to put it bluntly, not a real programming language.

What really saved HTML’s animatic bacon was JavaScript. JavaScript, being a "true" programming language, i.e. one that can figure out that 2+2=4 without your help, lets programmers compute and modify the contents of a web page on the fly. That is, if you know your Document Object Model, exposed by the browser for that purpose. So it goes like this: you first create a page in HTML. Then, once that page loaded, it invokes some JavaScript code, and that JavaScript code modifies the page, as if you had written a different HTML. Huh? Come again? Is that obstinately protracted or what? Well, from a design standpoint, HTML today is entirely designed like this, accumulated cruft piled on top of legacy junk. And it shows.

Now, maybe you think I’m exaggerating to make a point. And I am delighted to say I don’t even need to. Tao gets rid of so many levels of indirections for document writers that it’s borderline annoying to explain all the stuff you no longer need to do. Spend time thinking about the document, not about some Incomprehensible Document Indirection Object Theory or whatever. Start Don’t-Repeating-Yourself instead of just talking about it. Feel like your life is full of lovely fuzzy furry cute little animals.

Conclusion: Animations in HTML are done the wrong way. Tao is better in that respect, because the whole document is dynamic.

Objection 3.14 version 2: there’s already a standard for animations, it’s JavaScript

Matchstick extraordinaireTechnically, one can actually do a rotation in a web page using JavaScript. And much more, actually. With sufficient persistence, many highly capable programmers have built true marvels of engineering and art using technologies such as WebGL, Three.js, Processing,js and more.

But just because you can do it does not mean it’s a good idea. After all, if you push the reasoning to the limit, you can also do anything, including animations, by hand-coding everything in assembly language, starting with the OS. You can also spend 15 years building a four million pieces matchstick model. But the thing is: I don’t want to.

To illustrate my point, let’s create a text rotation in JavaScript, which is, arguably, easier than a four million pieces matchstick model (or… is it?) Let’s see what it takes, exactly, to do a simple little time-based text rotation with JavaScript and HTML. And no cheating with built-in CSS animations, I want a smooth back and forth motion with an expression that I can control, like in the Tao Presentations example above. With Tao, what I wrote to get a rotation of 30 degrees plus/minus 20 degrees along the Y axis (vertical in Tao) was:

rotate_y -30 - 20*sin time

Let me see. Of course, you can do a rotation like that. In JavaScript. Easy. Just give me a minute. Hmmm. Google "JavaScript rotation", easy enough. Several examples, all with a fixed rotation. Not good. OK, apparently I need to brush up my CSS. W3School this. Wikipedia that. Ah, the first few answers I found use jQuery, which I should avoid as it may not simplify things all that much. (Variation on an old joke: you have a problem, you think "I will use jQuery", now you have an entire collection of problems to choose from.)

Googling more. Ah, here is one answer that I might have to remember for when I need to scare young innocent kids out of a life of misery in web programming:

-webkit-transform: rotate(45deg); /* Chrome & Safari */
-moz-transform: rotate(45deg); /* Firefox */
-ms-transform: rotate(45deg); /* IE 9+ */
-o-transform: rotate(45deg); /* Opera */
transform: rotate(45deg); /* CSS3 */
filter: progid:DXImageTransform.Microsoft.Matrix(M11=0.70710678, M12=0.70710678, M21=-0.70710678, M22=0.70710678, sizingMethod='auto expand'); /* IE 7-8 */

Seriously? Four different vendors, six different notations, five of which look exactly the same and do the same thing yet differ in only a vendor specific prefix?

Now, it’s good to know that there are things you can always rely on. Like you can always count on Microsoft to make a mess of things in a furiously unportable way. They save you from the tar pit ("WebGL is bad, security, blah blah") by throwing you right into hot lava (DXImageTransform this, you bastard!). And please don’t forget the sizingMethod, it’s important. Don’t ask, just do it. And while we are putting DirectX junk in web pages, why prefix this Microsoft-specific piece of art with -ms- like all the other guys? I guess the reasoning was: "Microsoft is the standard, so we don’t need no stinking -ms-." They had room for improvement elsewhere as far as character count is concerned, but no, they got rid of -ms-.

I can’t help but wonder how we ended up with a "standard" so messed up that five identical transforms have five vendor-specific prefixes, while the single outlier with a completely different and proprietary approach is the one without vendor-specific prefix! Sorry, I just don’t get it… Did I digress?

Conclusion: In HTML, we don’t have one standard. We have half a dozen. Even for something as simple as a rotation. No wonder web programming is difficult.

Objection 3.14 version 2 reboot : Could we focus on the rotation please?

OK, we are straying away from our original JavaScript rotation problem. Back on track. Can I do my little rotation without jQuery? Hmm, yes, but not in a portable way. So should I consider the N most important browsers, return to jQuery, or stop caring entirely and just do what works on my browser?

Oh well, after almost half a diet Coke worth of fiddling around, a good dozen reloads in my web browser, one reproducible browser crash, and a fair amount of JavaScript debugging only to realize that I had misplaced a few parentheses, the best I could come up with is something like the code below. Which of course only works on Safari and Chrome, ensuring anybody using Firefox will see a total lack of animation whatsoever. Fixing that is "easy" (for a somewhat extended acceptation of "easy"), so I leave it as an exercise for the reader. So here it is, in all its glory:

<!DOCTYPE html>
      function dorotate()
      var element=document.getElementById("elem")
      var time=2
      function rotate() {
      var timer=setTimeout(function() {
         time += 0.025 = 'rotateY('+(-30-20*Math.sin(time))+'deg)'
      }, 25)
 <body onload="dorotate()">  
    <div id="elem">
      Hello World

Aaaaaaaaah. Can you sense any feeling of complete and profound satisfaction for a job well done? Nope. If Saturn V had been designed with the same flair for efficiency, Americans would yet have to reach the moon in their steam-powered balloons, pending a solution to the horse shit evacuation issue. After all that effort, the animation is not even the one I wanted (it animates relative to the center of the page, not to some other text), but hey, close enough.

For Tao, we were determined to remain ignorant of this kind of "state of the art". We decided, unilaterally, that the best way to describe a time-dependent rotation for a text writing "Hello World" was something like what I put in the original example at the beginning of this article. Sorry, can’t refrain from showing it again:

rotate_y -30 - 20*sin time
text "Hello World"

This solution is so obviously better that I feel an urge to explain. First, it’s shorter, and not just a little bit shorter. Second, it’s focused on the problem at hand, without all the extra irrelevant baggage. And finally, it practically speaks english, so the average eight years old can figure out what it does (OK, except for what a sine is, and why it creates a back and forth motion, but that’s a different issue, it’s basic math).

Conclusion: Animations can and should be taken into account from the start in the document description, not bolted on as an ugly afterthought.

Objection 42: The web has 3D, you can even write games with it

GamesHTML was invented on a NeXT workstation that was state of the art back then, but still slightly less powerful than the average mp3 player today. Since then, 3D graphics evolved, and then became ubiquitous, largely thanks to video games. And real-time interactive rendering is now the norm, again thanks to video games. It’s amazing just how much progress was made in the computer industry just to play games. Or display porn, but I digress.

Yet 3D did not really catch up in document description languages. There are a few 3D scene description languages, but most of them were designed for ray-tracing, so they render photo-realistic images, but they do so at the speed of an asthmatic slug on Vallium. Not designed for real-time, obviously.

The state of 3D on the web is just the same as for JavaScript. If you want the third dimension in a browser, you will need to learn several more dialects, such as CSS 3D and WebGL. You definitely need WebGL if you want to do anything serious, like games. WebGL is a JavaScript library derived from the venerable OpenGL, not really a full new language to learn, more like a collection of functions, but it’s still a pretty hairy beast. The always helpful JavaScript community also developed libraries such as Three.js to do really sophisticated things as long as you have way too much time on your hands. To really appreciate how much effort went into things like Three.js, here is a minimalistic web page using WebGL:

<body onload="start()">
 <canvas id="glcanvas" width="640" height="480">
    Your browser doesn't appear to support the HTML5
    <code>&lt;canvas&gt;</code> element.

This page only looks short because the actual script doing the work is not in it. Following the same "Why use one language when we can use two" philosophy of JavaScript, we need a separate piece of code for WebGL, using a syntax that is so totally different that it’s best placed in a different file. Yet the two pieces of code must connect using magic names, e.g you need to have glcanvas on both sides. This approach, reminiscent of what we saw earlier for ids, is called Do repeat yourself deja vu all over again.

So here is a minimal WebGL script, which does nothing but clear the canvas using a black background, with exquisite irrelevant details about depth testing thrown in for opacity:

function start() {
 var canvas = document.getElementById("glcanvas");
 initWebGL(canvas);      // Initialize the GL context
  // Only continue if WebGL is available and working
 if (gl) {
    gl.clearColor(0.0, 0.0, 0.0, 1.0); // Set clear color to black, fully opaque
    gl.enable(gl.DEPTH_TEST);           // Enable depth testing

At that point, you may have noticed that we already have two fallback mechanisms for older browsers. One, in the HTML code, deals with browses that are so crummy they don’t even have canvas. The other one, in JavaScript, deals with the lack of WebGL. Fifteen lines of code, two of them already dealing with missing features. Read what I wrote about standards earlier, and weep.

Now, is it just me, or is this code a tad bit too removed from storytelling? On a good day, the code above is probably a little bit easier to read than French Tax law translated in Chinese, but that’s about the only positive-sounding comparison I can think of.

One problem with WebGL is that it was designed and optimized for games. It’s quite powerful and can do many things, but it’s overkill and way too complicated for things like simple animations. Using WebGL for simple web page contents is a bit like using an aircraft carrier to go to the nearest supermarket: you spend most of your time solving nearly intractable problems like finding a parkings spot the size of a football field or coordinating flight space with the local authorities or understanding the intricacies of depth testing an depth functions. These are all issues which you might remain blissfully ignorant of had you chosen a simpler, more adequate tool, like a simple car, or like Tao.

On the other hand, common tasks necessary for storytelling are incredibly complex with WebGL, like displaying an image, showing some text, showing a 3D object, playing a movie. Now, when you think about showing a movie to your friends, would you rather talk about a movie or about a depth function, color buffers and dynamic textures?

Kittens in 3D!By contrast, Tao Presentations was designed from the ground up for simple, real-time 3D contents with a focus on storytelling. So to display a movie of cute kittens in a 3D scene, you’d simply write something like this:

import VLCAudioVideo
translate_z -4000
rotate_y 25
movie ""

Doing the same thing as the four lines above with WebGL is <sarcasm>left as an exercise for the reader</sarcasm>.

Conclusion: For games, WebGL is the right approach. For documents, it’s the wrong tool. Tao Presentations is designed for 3D documents, and it does that task much better than WebGL.


Ultimately, we write documents and create presentations to share a story, to show things. This is the topic I cover in the second (and last) part of this article.

Christophe de Dinechin


No customer comments for the moment.

Only registered users can post a new comment.