SkrivML: A lightweight markup language

What's depressing to me -- and my depression is not alleviated by reading Skriv's syntax -- is how similar they are and yet how none of them deal with the many kinds of typographical formatting that are routine in printed books.

For one simple example: Poetry. (Case in point: [1]) People who publish poetry expect as a matter of course to control their line-breaks and their indention in support of their meaning, and to center lines of text. Only AsciiDoc ("verse" block) and Skriv support literal line breaks (outside of monospaced code blocks). I don't know of any of the ascii markups that support centered text, or controlled indents.

Another simple example: Drama, play scripts. (e.g., [2]). Act and Scene titles are centered; character names are often small-cap (try commanding small-cap in any ascii markup); in older published plays it is common to have entrances and exits right-aligned: "[Exeunt" in the right margin. Both verse and drama (not to mention legal documents) often have reference line-numbers in the right margin, on the same line as left-justified text.

Quoted correspondence often has dates and signatures right-aligned. AsciiDoc supports right-alignment only in the single case of the citation of a block quote. I don't know any other text markup that allows even that much.

In short, the couple of dozen extant markups are solving the same limited range of problems over and over for no better reason than general NIH, while ignoring the much wider gamut of published formatting.

[1] http://carl-sandburg.com/chicago.htm

[2] http://www.shakespeare-online.com/plays/macbeth_3_1.html and this is a wretchedly ugly example but look at the source! It's a TABLE!

- I dislike the fact that line returns are kept inside paragraph. I use automatic linewrapping in my text editor to produce neat markdown files that look clean both when rendered and when viewed raw.

- I would like to have the option of displaying vanilla smileys :)

Otherwise quite nice!

{{/path/to/img.png}} vs. Markdown's 

List syntax is nice and reminds me of wiki syntax. I've always favored that style over Markdown's list syntax. Actually a lot of it reminds of wiki syntax. Tables also looks like a breeze to remember how to write.

I like this.

EDIT: I do like the link syntax, though.

The one thing I really like in Skriv is the ability to assign CSS classes to paragraphs or divs. That is something I have wanted in an abbreviated form for a while. I wrote an extension to do this in my own Creole parser but most of the time I am using someone else's or writing in Markdown so I can't use the syntax.

What if you want to emphasise parts of a word? I know I've had to do that at least a few times. This seems like one of those things that felt like a good idea and does work most of the time, but then really infuriates you when you find out that it's virtually impossible to do it.

It makes for exceptionally tidy source files, with neat folding of headers. Tables are a breeze. You can easily run the code in your code blocks. Adding css styling is a piece of cake.

All this an only a couple of hundred key combinations to memorise.

One possible pitfall in syntax, though: two dashes within one sentence would be translated to strikeouts -- which I could only come up with context-sensitive fixes -- which would violate the core principle (of removing ambiguity).

This increased diversity will only push Markdown's dominance and not help to get better alternatives _at all!_

But there is no official spec, development of the syntax grew stale (from the start, thanks to Gruber)¹, and hence the language heavily suffers from fragmentation²: people want to be able to do more with light-markup, so they build extensions, or fork the language altogether. The troubles with Markdown are discussed in various³ places⁴, John MacFarlane built a formalized comparison tool⁵, but as of yet, there is no joint effort to cooperate on a lightweight markup standard.

There are a few interesting projects that dare to forsake Markdown and try their luck: Fountain.io⁶ (a domain specific light markup language for playwriting), SkrivML⁷, Strictdown⁸, and z.m.l.⁹

Then there are, of course, the many predecessors of Markdown, which prove that Markdown (or light-markup in general) is not the imprescriptible privilege of its self-proclaimed benevolent dictator for life, and some of which are still widely used in various communities: Setext (1992), AFT (1999), Grutatxt (2000), AsciiDoc (2002), MediaWiki (2002), reStructuredText (2002), Org-mode (2003), Textile (2004)…

We need an extensible lightweight markup language of sorts, a “lxml”, if you will, and we need to work on it together.

If we want ever to succeed in establishing a true standard light markup language, the big challenge is not only to focus on extensibility, but also to reconcile the various existing and future syntaxes, and take care of backward-compatibility (with plain Markdown), as much as possible. As mentioned by quite a few commenters here and elsewhere, weeding out conflicting syntax should be the first thing to do.

For starters, I begun a concordance¹⁰, listing the various delimiters and patterns used by competing lightweight markup languages. (Very rough draft, though, and need to think about a way to formalize the data, to make more accurate comparisons, and consequently, better decisions on the syntax of a future xlml.)

¹ http://blog.codinghorror.com/the-future-of-markdown/ ² https://github.com/rhythmus/markdown-resources ³ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not... ⁴ https://medium.com/the-future-of-publishing/495ccfe24a52 ⁵ http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-... ⁶ http://fountain.io ⁷ SkrivML ⁸ https://github.com/jakwings/strictdown ⁹ http://www.z-m-l.com ¹⁰ https://github.com/rhythmus/markdown-resources/blob/master/l...