PIDGIN MARKUP FOR WRITING, OR HOW MUCH CAN HTML SUSTAIN? (#📎)
Artyom Bologov <pidgin@aartaka.me>

<assets/pidgin.png> (Image of a silly pigeon drawing. Its head has a “<” sign beak and a “/>” (see the HTML reference?) plumage. On its body, “HTML” is written in bright letters. Along its tails, “AARTAKA.ME” is written as if continuing it.)

I am an HTML extremist <hypertext.txt>.
There’s this argument I often hear: “But HTML is cumbersome to write!”
Wrong, as many other myths about HTML <falsehoods-html.txt>.
In this post, I’m detailing how I write my dialect of HTML and why it’s easy.

This Pidgin HTML dialect is intimately tied to my website setup:
I’m using ed(1) as my Static Site Generator <this-post-is-ed.txt>.
Which means the setup is:

• I write my Pidgin HTML in `.htm' files.
    It’s a standard HTML extension, but it’s useful to differentiate from the resulting `.html' for build purposes.
• I preprocess SSI-like comments and include files.
• I convert overly smart and (slightly) weird tags into valid HTML.
• And then I send the result to
  Another Person’s Computer™ <codeberg-pages.txt>
  for you to see on aartaka.me.

This setup is no rocket science, doing sloppy tags, regex substitutions, and shell scripts.
And yet it results in a dialect of HTML that’s easy/er to write.
And almost standard/conventional.
Here’s a set of engines I’m testing my markup with:

• Dillo <dillo.org>
  • w3m <w3m.sourceforge.net>
  • Firefox/LibreWolf
  • (Ungoogled) Chromium
  • WebKitGTK browser engine
  • Plump <github.com/Shinmera/plump>, an HTML parser for Lisp.

So yeah, it does work everywhere, even as the raw source form.

You can see the initial Pidgin HTML for this post rendered at
pidgin.htm <pidgin.htm>, and
download it to preview the text behind it <pidgin.htm download>.
On to the quirks then <developer.mozilla.org/en-US/docs/Web/HTML/Guides/Quirks_mode_and_standards_mode>!

SMART TAGS (#smart)

HTML links are slightly painful to type out <merveilles.town/@aartaka/115669971371343412>.
So I made my own syntax, knowing that my build regex will expand it for me:

===================================  ===================================
<a just.htm <just.txt>>local link to other post</a>
<a //something.com>Scheme-relative link <url.spec.whatwg.org/#scheme-relative-special-url-string></a>
<a aartaka.me <aartaka.me>>Arbitrary link without https:// formalities</a>
==================== Simplified links ====================

There’s a bunch of other tags, like `<c>word' for simpler `code' tags.
And shorter `<img assets/pidgin.png Image of a silly pigeon drawing...>'.
Not much, but more than enough for comfortable writing.
Now to the more grand things.

IMPLIED END TAGS (#implied)

I think this is the heritage of sloppy HTML 1/2/3 programming.
You know, with shortcuts following authors’ practice.
The primordial chaos reigning in the early Internet.

Long story short, you don’t have to close `<p>'.
Its end tag is implied and closed whenever e.g. the next opening `<p>'aragraph tag is encountered.
Spec: li, dt, dd, td, and some others also work this way <html.spec.whatwg.org/#closing-elements-that-have-implied-end-tags>.
This is valid processable HTML:

===================================  html ===================================
<p>
hello

<p>
another hello

<ul> one
<li> two
<li> wait, it’s not an ordered list?
</ul>
==================== Implied end tags in action ====================

this ul... {
  You may’ve noticed the `<ul>' followed by text.
  This is another of my shortcuts.
  It looks alright (indented) when opened from source `.htm' file.
  It’s easy to type.
  And it’s a simple substitution away from a valid `<ul> <li>' list.
}

Having these, I can generate sensible HTML with ed(1) scripts.
While having the convenience of shortcuts in standard HTML.
All according to the spec!

CLOSING TAG SPACE (#closing)

Here’s a fun one: HTML spec forbids putting anything into closing tags (anything after `</tag').
Yet… everyone parses it just fine.
So I can e.g. put things into the epilogue of a `pre' tag as a caption for the code block:

===================================  html ===================================
<pre html>
<!-- ... -->
</pre Example of closing tag captions>
==================== Example of closing tag captions ====================

I mean, it’s not a caption per se.
And it renders as plain `<pre>' when previewed in `.htm' source.
But once I process it with my build scripts, it expands to a proper `<figcaption>'.
Without the need to write all the formalities out myself.

ARBITRARY ATTRIBUTES (#attributes)

A thing partially related to closing tag contents: HTML allows anything as attributes.
This previous sentence might work well as an attribute set:

===================================  html ===================================
<span HTML allows anything as attributes>...</span>
<!-- turns into -->
<span HTML="" allows="" anything="" as="" attributes="">...</span>
==================== Anything you put into tags is attribute, actually ====================

I’m using that for e.g. tables and `<details>':


===================================  html ===================================
<details this ul...>
You may’ve noticed the ...
</details>
==================== Effective leading tag space use ====================

And I’m using `<h2 id>' as a shortcut for headings with IDs (`<h2 id=id>').

MAGIC IE COMMENTS AND SERVER SIDE INCLUDES (#comments)

<assets/pidgin-comment.png> (A line of text. On it, highlighted IE comment “[if IE]...[endif]” is added, and inside it, “oh, don’t mind me” is written. Playing with the fact that most browsers ignore IE comments.)

In case you ever opened the inspector
on some major site <mozilla.org>,
you might’ve seen these `[if IE]' comments.
Basically Internet Explorer specific comments that only IE evaluates.
Other browsers perceive them as mere comments.

===================================  html ===================================
<!--[if IE 9]>
    <script src="https://www.mozilla.org/media/js/lib-ie.cf16e08599c3.js"></script>
<![endif]-->
==================== Example IE conditional comment from mozilla.org ====================

These are useless in the modern post-IE world.
That’s why I’m exploiting them to generate format-specific content.
Say, making a link footer when generating Gemtext from this Pidgin HTML:
(I've since removed Gemtext backend from this site, unfortunately. Gemtext is too primitive.)

===================================  html ===================================
<!--[if GMI]>
=> index.gmi Back to home page
=> about.gmi About & Contacts
=> uses.gmi Tech I Use
=> projects.gmi My projects
&lt![endif]-->
==================== GMI-specific content via IE comment ====================

Another point of reference might be
Server Side Includes <wikipedia.org/wiki/Server_Side_Includes>.
Initially Apache-specific format of commands embedded into HTML (or, rather .shtml) pages.
Allowing file inclusion, conditional expansion, shell/CGI command execution etc.
A much needed logic-ful HTML extension.

So I’m using SSI as an inspiration, making my own `#include' and `#exec' directives.

===================================  html ===================================
<include template/footer>
as a shorthand for
<!--#include file="template/footer" -->
==================== SSI-like inclusion command ====================

This is recognized as a mere starting tag.
Or, in case of the SSI version, as a comment.
Harmless.

PIDGIN HTML IS STILL HTML (#still-html)

Let this post be a praise to

• shortcuts of HTML,
• its simple user-facing nature,
• and the universality and power of Web Platform.

Pidgin HTML is made possible by sloppiness of the standard/quirks HTML.
It’s still valid HTML, but one that is much easier to write.
Good for authoring as a hypertext alternative to Markdown.
And other Lightweight Markup Languages.

Don’t be afraid of HTML.
Write Pidgin HTML.


CC-BY 4.0 <creativecommons.org/licenses/by/4.0> 2022-2026 by Artyom Bologov (aartaka,)
with one commit remixing Claude-generated code <codeberg.org/aartaka/pages/commit/a91befa>.
Any and all opinions listed here are my own and not representative of my employers; future, past and present.