Article markup language.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
ltdk f34334581b Drafting 1 year ago
.gitignore Initial commit 2 years ago Initial commit 2 years ago Initial commit 2 years ago
Makefile Initial commit 2 years ago Drafting 1 year ago


Article markup language.


Available via the Anti-Capitalist Software License for individuals, non-profit organisations, and worker-owned businesses.


Currently, this is just an idea for a project that has started some work but I can't find it for now. The goal is to have a format for writing articles that would replace Markdown and enable more markup without adding complexity.

The name "rtcl" can stand for rich-text content language, or just "article" with the vowels removed.


The whole premise of rtcl is that rather than simply formatting text, it's designed to lay out content. So, rather than the basic unit of content being a paragraph, like in markdown, the basic unit of content is a section. A single piece of rtcl is called "data" rather than code or text.

In general, a valid string of rtcl will be split into one or more sections, which themselves can contain one or more sections. In general, when a single rtcl represents a self-contained piece of content, it's called an article, although there's no physical distinction between a single section and an article.

There are two primary parsing modes for rtcl based upon this idea: a piece of rtcl data can represent either multiple sections (rtcls), or a single article (rtcl). If the actual content of an article comprises multiple sections, then those sections are wrapped in an additional section to ensure that the article is only a single section, whereas otherwise the sections would be kept separate from each other. The actual syntax for both formats is the same; the only difference is how the resulting content is used.


Sections in rtcl form a simple tree structure, where each section is categorised as either content or a container. Containers contain two or more sections and no additional content, whereas content sections cannot contain further sections. When actually interpreting rtcl data, a container with exactly one section is identical to a content section; although rtcl data can be semantically treated this way, stating that containers explicitly have two or more children helps ensure that "long branches" don't exist, i.e. containers within containers that ultimately only contain a single content section.

When parsing rtcl, note that it's actually impossible to have an empty section. If there is any point where a section could be considered empty, it should be treated as an empty content section rather than an empty container.

Sections can optionally have a name, and this name is used to help annotate where sections begin and end. Section names have to be valid unicode XID identifiers according to UAX31 with the added possibility for including digits at the beginning of the identifier; this basically means that they can't contain spaces, emoji, or weird punctuation. The start of a section is indicated by one or more plus signs (U+2B), the identifier, and a new line; the end of said section is indicated by an equal number of hyphen-minus signs (U+2D), the same identifier, and a new line. Any amount of white space can be added at the beginning of the line, between the signs and identifier, and at the end of the line. Identifiers may be repeated across the same piece of rtcl data, and a lack of identifier can be treated as using an empty string for an identifier.

When closing sections, any ambiguity should be resolved by closing the most recently opened section. It's considered bad form to rely on this ambiguity, however, and parsers may want to warn the user about it.