<1>
<2.1> <2.2>
<1>
<2>

Tree Markup Language - TML

Because HTML is TMI

The DOM was originally meant for text and markup. Now we've shoved entire apps into it, and are fighting whether or not to put a Shadow DOM inside our DOM nodes. We have it backwards.

The Shadow DOM doesn't go on the inside, it goes on the outside, around the <body> tag we lost. This tag used to just hold straightforward markup, annotated with some anchors and inline font styles. Now it holds all of Gmail, right between the fonts.

This file (view source!) is an idea on how to evolve away from HTML without breaking it. In it, you'll find a naked DOM, stripped clean of the usual <html>, <head> or <body>. Instead, there's just <layout>, <style> and <html> separately. Meet the hypothetical <!DOCTYPE tml>.

Absent an initial <head> or <body>, the DOM will reorder it back to what it should be in HTML.

  <!DOCTYPE html>
  <link rel="stylesheet" href="shim.css">
  <script src="shim.js"></script>

  <!DOCTYPE tml>
  <layout if="width > 600">

    <header><1></header>
    <grid divide="4x1">
      <box width="3" class="big"><2.1></box>
      <box><2.2></box>
    </grid>

  </layout>
  <layout if="width <= 600">

    <header><1></header>
    <box><2></box>

  </layout>

  <style src="example.tss"></style>
  <style>
  box.big text {
  	font-size: 16px;
  }
  </style>

  <html>
    <h1>Tree Markup Language</h1>
    <h2>Because HTML is TMI</h2>
    <pbr>
    The DOM was originally meant...
    <p>
    The Shadow DOM doesn't go on...
  </html>

The idea is to write your content as a linear piece of HTML and divide it into paragraphs with <p>, pages with pagebreak tags, <pbr>. Or just regular HTML if you like.

Then you slot that into boxes by defining numbered placeholders inside layouts. <1> is page 1. <2> is page 2. <2.1> and <2.2> is page 2 spread over two blocks, in that order.

Multiple layouts can be added for responsive design. Sublayouts can be included by reference. We already write our static site generators this way.

It doesn't work of course, it's just an idea. But with a JavaScript layout polyfill, that can be solved. What matters is that it's a completely new document structure that is still compatible with HTML, and is accessible without JavaScript in the browsers of today.

It doesn't even have to be this particular layout model, it's just about having a practical separation between layout, style and content. About having <masonry> be a tag.

Aren't we still just marrying ourselves to HTML and its escaping? Well yes, but this gives us a way out, like the UTF-8 to Unix's ASCII. HTML does allow for (almost) arbitrary character data with CDATA. We can supply <markdown> instead of <html> if we like, and again, polyfill it in, perhaps wrapping it in <pre> tags:

  <layout>
    ...
  </layout>

  <style>
    ...
  </style>

  <markdown><![CDATA[
    ...
  ]]></markdown>

Isn't that how most techies blog these days? And doesn't that text still get parsed by search engines? It's not a *miracle cure*, but I think it has potential. It's basically multipart MIME for HTML, there is no reason you only need one chunk of content of a single type. Though the data binding mechanism would obviously get a bit more complicated in that case. I switched from HTML to Markdown one paragraph earlier, and you didn't really notice. --Steven