Steppe

A simple HTML to HTML transpilation designed to save you keystrokes when writing raw.

I prefer this to using custom HTML languages that involve an external dependency or toolchain that includes parsers, and so on. Those approaches seem like overkill when we already have a parser available.

Note to self

There may be a way to transpile JS to HTML in an even nicer syntax. I'll have a think about it.

I also prefer this to using a new DSL for HTML, when we already have a language that everyone understands.

Basic idea

HTML is a tree, so you need nodes that can represent any HTML node but cost you less keystrokes.

To represent any node, you need to be able to have both fecund nodes and leaf nodes, where fecund nodes can have child nodes.

So to transpile HTML to HTML with less syntax the idea is to use the HTML tag name of the guest element as an attribute name in a shorter non-void host element, thereby saving you keystrokes on the closing tag, and in the case that the original node had no children (or is void), you can just use a void host element. In the case of a void guest element you may as well use that same void element itself, because that saves more keystrokes than using a guest.

For other attributes on the guest, just set them on the host.

So our transpiler will be a system of parsing a DOM tree, and replacing all hosts with their guests, or leaving the guests as they are in the case of void nodes with no attributes named like a tag name, coupled with a choice about which nodes we will use for the fecund host and the leaf host, as well as a set of rules for resolving or preventing any potential conflicts in the case that an attribute on a void guest (having itself the same tag name as the standard void host) is the same as a valid tag name, which would make it ambiguous whether that is to be parsed as a void guest, or a void host.

Design

For the choice of host elements, remember we need one element capable of containing others (being fecund), and one void (since we don't want to have to put an end tag where none is required, that being the case when there are no contained elements).

We would also like the tags to be as short as possible, so something like section is out, and also require that the fecund host is capable of containing, at the very least, the void host, and, ideally, all possible void elements.

By capable of containing we mean that it is "valid HTML" in the sense that the browser will not assume it is a mistake or invalid and then modify the order / hierarchy of the DOM we have written to make it comply to what it assumes is correct.

The shortest void elements are br and hr.

But since we would also like the HTML to probably not have any side effects, I think we can settle on br as being the void host.

For the fecund host, the shortest elements are: a, b, i, p, q, s and u.

"Key" considerations

I think it comes down to a matter of aesthetics, and fine tuning the design for keystroke optimality.

Based on the assumptions that most coders / designers will be using a QWERTY keyboard (I said, most, not all, Devorak acolytes), and the following observations about typing patterns around the tag name letter (TNL):

• the key before the TNL will be <
• they key after the TNL will be
• they key before the TNL will be /

Because the placement of the < and / are on the right-side of the right-hand's region, if we make the tag name also struck by the right hand, the right hand shall be overloaded.

Since the left hand will, probably, be resting in its usual position, the easiest key to pick is the a.

The b is also nearby but the left hand must move from its usual position to strike it.

The s is also another candidate, as is the q.

However, the a will not be able to contain other as so this makes it unsuitable.

Now the choice is between s and q.

Semantics

We would also like, if possible, the tags we pick as hosts to have some sort of "semi valid" or "comprehensible" semantic meaning as well.

This is not a technical requirement, but I think it's desirable, and something about writing code that "makes sense" based on an already familiar conceptual model, that is slightly different, will be a much better design that writing code that would "jar" with an existing technical model.

For this reason I think q (which means quote) is a better choice than s (which means incorrect), even tho if your fingers rest on ASDF one must first move to strike q.

Just to be thorough, let's see if we can do any better than q by considering a sequence that begins with a left-hand letter and is two letters long.

The two letter long tag names in HTML are:

• br
• dd
• dl
• dt
• em
• h1
• h2
• h3
• h4
• h5
• h6
• hr
• li
• ol
• rb
• rp
• rt
• td
• th
• tr
• ul

Of these, those that start with a "left hand" letter are:

• br
• dd
• dl
• dt
• em
• rb
• rp
• rt

And of these those that keep mostly to "the left" without requiring the left hand to shift into the center are:

• dd

So, just one tag: dd

I think dd is nice because it means, definition, which is very appropriate for what we are doing.

Draft Design Refinement

Therefore, based on these considerations, we have a void host of br and a fecund host of dd.

Let's try to test these out on some experimental examples:

  <article>
    <header>
      <h1>Steppe</h1>
      <h2>The steppe byline</h2>
    </header>
    <section class=main>
      <blockquote>Something interesting</blockquote>
      <p>Beginning
      <p>Middle
      <p>End
    </section>
    <aside>
      <strong>Also note</strong>
      <p>First point
      <p>Second point
    </aside>
    <footer>
      <ul>
        <li><a href=#related-1>Related link 1</a>
        <li><a href=#related-2>Related link 2</a>
      </ul>
    </footer>
  </article>

Thinking about this I just don't want to use dd. It's too much.

Let's use s:

  <s article>
    <s header>
      <s h1>Steppe</s>
      <s h2>The steppe byline</s>
    </s>
    <s section class=main>
      <s blockquote>Something interesting</s>
      <s p>Beginning
      <s p>Middle
      <s p>End
    </s>
    <s aside>
      <s strong>Also note</s>
      <s p>First point
      <s p>Second point
    </s>
    <s footer>
      <s ul>
        <s li><s a href=#related-1>Related link 1</a>
        <s li><s a href=#related-2>Related link 2</a>
      </s>
    </s>
  </s>

The good thing is this is still HTML and still looks very much like our original document.

And it reads easy. I'm reading it as: say <tagname> or show <tagname>

I think we can do a bit better tho. Hosts like <s p> and <s a> are unnecessary, so let's replace those.

  <s article>
    <s header>
      <s h1>Steppe</s>
      <s h2>The steppe byline</s>
    </s>
    <s section class=main>
      <s blockquote>Something interesting</s>
      <p>Beginning
      <p>Middle
      <p>End
    </s>
    <s aside>
      <s strong>Also note</s>
      <p>First point
      <p>Second point
    </s>
    <s footer>
      <ul>
        <li><a href=#related-1>Related link 1</s>
        <li><a href=#related-2>Related link 2</s>
      </ul>
    </s>
  </s>

I like this, we've cleaned it up, and even replaced things like <s ul> and <s li> which are more costly than just writing <ul> and <li>.

And it reads really easy. I'm reading it as: substitute <tagname>

Numbers

According to my calculation, it's a modest saving of around 25 strokes, or approximately 5% less than what you would write with HTML.

This is not much, but if you consider that Olympic athletes constantly push for small increases in performance, and consider that typing, for a working programmer, is a very high level skills, a small performance increase is something desirable.

The question for myself is, are the costs of using it too high, given any benefit?

I don't know the answer to that right now.

Conclusion

I think this design has something to it. I have to consider whether I would use it in writing my own HTML. And then how I would integrate it into my templating / views.

Even tho I'm making this for myself I am curious what other people think and consider. So what do you think, is something like this worth it for you?