> More or less, what I want from markup is to convert a text string into a document tree:
enum Element {
Text(String),
Node {
tag: String,
attributes: Map<String, String>
children: Vec<Element>,
}
}
fn parse_markup(input: &str) -> Element { ... }
> Markup language which nails this perfectly is HTML.
The reason HTML nails it perfectly is because this is modeled after HTML.
If I were to make up a markup language, I wouldn't follow that model.
In particular I would get rid of attributes which to me are a restricted kind of children with a specialized syntax.
This is both unnecessary and undesirable in many cases.
The major problem with attributes is the <String, String> mapping. Once something is defined to be an attribute, it cannot be sensibly extended without creating an unnecessary problem.
For example the `class` attribute in HTML looks like it was originally designed to hold a single class name. Then people realized that it would be desirable to have multiple classes per element.
So, to keep things backwards-compatible, the value of the attribute was extended to hold a space-separated list of classes instead. Essentially creating a little DSL inside of the attribute's value.
If `class` was instead a kind of child, initially limited to a single instance per element, extending to multiple instances in a backward-compatible manner would not require introducing the DSL. It would be natural. Just allow many `class` children.
A valid argument in HTML in favor of attributes is conciseness. But that's an artifact of the syntax.
We could make up a language with syntax for nodes as concise as HTML attributes, eliminating that argument.
> It feels like there’s a smaller, simpler language somewhere
Certainly.
I have experimented with many different designs for such a markup language on top of Jevko[0]. One interesting design that trivially maps to HTML looks like this:
h1 [Title]
p [
paragraph
]
p [
[paragraph with a ]
a [
href=[...]
[link]
]
]
Another one looks like this:
[h1][Title]
[p][paragraph]
[p][
paragraph with a
[href[...] a][link]
]
Both are extremely simple and minimal, but also extensible and lend themselves to writing by hand.
[0] https://news.ycombinator.com/item?id=33287620
The reason HTML nails it perfectly is because this is modeled after HTML.
If I were to make up a markup language, I wouldn't follow that model.
In particular I would get rid of attributes which to me are a restricted kind of children with a specialized syntax.
This is both unnecessary and undesirable in many cases.
The major problem with attributes is the <String, String> mapping. Once something is defined to be an attribute, it cannot be sensibly extended without creating an unnecessary problem.
For example the `class` attribute in HTML looks like it was originally designed to hold a single class name. Then people realized that it would be desirable to have multiple classes per element.
So, to keep things backwards-compatible, the value of the attribute was extended to hold a space-separated list of classes instead. Essentially creating a little DSL inside of the attribute's value.
If `class` was instead a kind of child, initially limited to a single instance per element, extending to multiple instances in a backward-compatible manner would not require introducing the DSL. It would be natural. Just allow many `class` children.
A valid argument in HTML in favor of attributes is conciseness. But that's an artifact of the syntax.
We could make up a language with syntax for nodes as concise as HTML attributes, eliminating that argument.
> It feels like there’s a smaller, simpler language somewhere
Certainly.
I have experimented with many different designs for such a markup language on top of Jevko[0]. One interesting design that trivially maps to HTML looks like this:
Another one looks like this: Both are extremely simple and minimal, but also extensible and lend themselves to writing by hand.[0] https://news.ycombinator.com/item?id=33287620