Friendly Markup Language

Friendly Markup Language, abbreviated as lowercase fml.

Inspired by Markdown, its main goals are minimalism, expressiveness and compatibility with both web and non-web targets.
Purpose-made for the Starling communication protocol.

Friendly Markup Language and its specification are licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License.
This crate's source code is licensed under the GNU Affero General Public License.

Crate state

This crate uses semantic versioning, and as such it is currently in development, not having yet reached its 1.0 release.
This means that right now, anything can change at any time.

Things left to do:

• Write a more thorough specification
• Finalize AST
• Finish writing the parser crate feature
  • Add parser test cases
• Add HTML render crate feature

Why not use Markdown?

Full HTML+CSS allows for a lot of customizability, forcing developers of non-web frontends to pick which elements and style properties will be implemented in a round-about way, and which will be omitted and not rendered.
In short, its scope is beyond what a lot of environments allow or need.

Additionally, from a user-perspective, having to write an HTML element with CSS style properties by hand to achieve basic styling is a lot of work. This is something fml tries to address.

Concepts

No token overlapping

fml expects well-formed, properly-nested elements.

Non-emptiness of token bodies.

The body of each token must not be empty.
If the body is empty, the token syntax will be interpreted as plaintext, and the function syntax will not be used.

What non-emptiness means:

• For tokens written in syntax which need to be terminated with itself, this there must be 1 or more non-whitespace, non-fml-token symbols present in-between the two tokens, or in the case of the Code styles: 1 or more symbols, whitespace allowed ( is valid.).\
• For all other tokens, this means there must be 1 or more non-whitespace, non-fml-token symbols after the token.

Definitions

Content : any isolated sequence of text, for example: a file or one message.

Section : a section starts either at the first non-whitespace glyph of the first non-blank line either at the start of the content or after the last section has ended.
A section lasts either until a blank line is found, or until the content ends.
The blank line in-between the end of one section and the beginning of another is preserved during processing and display.
Naturally, line-breaks (those created by carriage-return) and leading whitespace inside of a section are both preserved during processing and display.

Code-block interpretation

fml tokens as plaintext

Inside of both Code styles, all fml tokens are interpreted as plaintext with two exceptions.

1. The first exception is the ending of the code style. If the closing backticks match the amount needed to close the style (1 for Inline and 3 for Block), they will be interpreted as an fml token and will terminate the style.

2. The second exception is preventing an unwanted termination by escaping one of the backticks with the escape token. For this purpose, the backslash character will only be interpreted as an fml token if it directly precedes a backtick.

fml tokens

Constraints

Constraints for each token are defined in the footnotes linked to each fml token cell.

The exhaustive list of mandatory fml tokens

fml tokens optional for implementation:

Since, unlike LaTeX, typst is rather human-readable, it shouldn't be too much of a compromise to allow some implementations to render typst as plain-text surrounded with $ signs, letting other implementations compile and render it properly.