5 ms·

SkrivML: A lightweight markup language

41 points by rhythmvs 12y ago

ultimatedelman 12y ago
This seems like a more verbose version of Markdown :\ Maybe the only advantage is displaying code, but everything else is either equal to or more verbose than Markdown. EDIT: I do like the link syntax, though.
- orclev 12y ago
  Yeah, that was basically my reaction as well. They tweaked Markdown a bit, changed a few things around, but it's pretty much identical to Markdown. I don't really see any big wins here. This XKCD seems somewhat appropriate: http://xkcd.com/927/ http://xkcd.com/927/
  - handyman5 12y ago
    Is it sad that I recognized the comic from the context and the number in the link?
    - thegeomaster 12y ago
      Just happened to me. The second I clicked it I figured out which one it was.
    - boomlinde 12y ago
      Sad but not very surprising: https://hn.algolia.com/?q=http%3A%2F%2Fxkcd.com%2F927#!/comment/forever/0/http%3A%2F%2Fxkcd.com%2F927 https://hn.algolia.com/?q=http%3A%2F%2Fxkcd.com%2F927#!/comm...
  - NaNaN 12y ago
    You should be happy that it is not named Yet Another Markdown Language. And I don't think there will be a standard Markdown in front of the people who shout out HOLY MARKDOWN until John Gruber release an update.
- smilekzs 12y ago
  "Verbose" seems to be a trade-off for removal of intrinsic ambiguity (and the resulting standard wars) within markdown, which I speculate as the reason we still haven't come up with one "standard markdown" despite many calling for it. IMHO this took minimal yet established markups from various wiki and markdown-ish syntaxes, further simplified them, finally approaching what we wanted as a "standard markdown" in the first place.
norswap 12y ago
Criticism: - 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!
- pandatigox 12y ago
  I agree with you on the line returns. It really annoys me when it's not rendered like a WYSIWYG. Especially when I'm quoting or writing something like a poem. Nevertheless, I quite like how CSS classes fit nicely into the syntax
  - JasonFruit 12y ago
    If I read it right, you're actually disagreeing.
- krbbltr 12y ago
  Yeah, the line breaks ruin it for me. I don't understand the point of it, either. Poems and the like could easily be handled by a special mode, similar to code blocks. Are there other situations where forced newlines would be useful? There may be, but I can't think of any. Either way, severely restricting how text – source code – can be organized just to simplify some rare special cases seems like a bad idea. It's a shame, since the rest of it looks really nice.
demetrius 12y ago
I hate '' for italic. It is strange from semantic point of view (I definitely don’t agree with the "its syntax is intuitive" claim), and it would force me to change the keyboard when I’m writing in Russian.
- gfv 12y ago
  Doesn't Russian use angular quotes or double quotes where angular ones are not available?
smilekzs 12y ago
Despite the negative tone here, I feel like the direction they're working towards. 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).
thegeomaster 12y ago
It looks nice, but do we really need another one of these?
- NaNaN 12y ago
  Better than just seeing Markdown/reStructuredText/AsciiDoc/Textile/... there. I'm designing a new markup language, too. Happy to draw inspiration from Skriv. Not all markup languages are good for blogging, especially for different spoken languages. At least, both Markdown and reStructuredText are not very good for Chinese writings.
  - akurtzhs 12y ago
    What problems do Chinese writers run into when using Markdown or reStructuredText?
    - NaNaN 12y ago
      Most inline markups require spaces surrounding the text, and Chinese do not need spaces between words. Although reST provide "\ " to remove the spaces from output, it makes the document ugly.
coderdude 12y ago
I like how images are written: {{/path/to/img.png}} vs. Markdown's ![](/path/to/img.png) 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.
- ilaksh 12y ago
  Can we just make a new version of Markdown that supports that and Skriv | http://skriv.org http://skriv.org for links?
  - coderdude 12y ago
    Skrivdown? :) You'd have to switch to Skriv's syntax for headers since Markdown's headers and Skriv's ordered lists use the same syntax. Another thing I'd change about Markdown would be to remove multiple syntaxes for writing the same element. For example, with Markdown you can use *, -, or + to create unordered lists. That might exist for some reason I don't know about but I don't like it.
userbinator 12y ago
These markups can affect full-words only, they are not effective if they are written in the middle of a word. 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.
- fernly 12y ago
  As in documenting an API or command syntax, when you want to go from mono (literal) to italic (variable input) with no break. In Skriv it would be ##--input=##''filename'' except that (a) Skriv requires a space and even if it didn't, (b) the -- would be an unbalanced strikeout code. Not to worry, reST doesn't do it either.
paulyg 12y ago
I jump between Creole and Markdown and this seems like an interesting mashup. Though I don't like all the choices made. I have been thinking lately about just combining Creole and Markdown into one master markup lang. 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.
fernly 12y ago
I've been comparing these things (ascii markups) lately, mainly because I'm writing software to support an organization with a long history using not one, not two, but three unique ascii markup conventions. Could these somehow be translated into a more or less standard one, and gain the freedom of output provided by e.g. Pandoc? 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 http://carl-sandburg.com/chicago.htm [2] http://www.shakespeare-online.com/plays/macbeth_3_1.html 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!
- anon4 12y ago
  It's a TABLE! I believe that's because it's a table semantically. I mean, look at it - three columns, fixed width, sometimes columns 1 and 2 merge together. That's a table any way you look at it. I never understood people's fear of tables - they're awesome, they're easy to control the lay out of, browsers support them just fine, they can be as flexible as you want. And if you feel sick every time when you type a <table> tag, you can specify them in CSS nowadays.
estebanrules 12y ago
I like the syntax. However, how many markup/markdown languages do we need?
OliverD 12y ago
I would change ''italic'' to italic. It is easier to remember how to create a bold and an italic word if you only have to remember one sign. Besides the ' sign is not very common in some countries.
MarcScott 12y ago
I've yet to find any markup language that has the power and flexibility of org-mode. 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.
- fernly 12y ago
  Thanks for pointing out YALML (lightweight markup language) for my collection! With regard to my comment below, I note that Org does support a Centered mode for paragraphs and a Verse mode in which line breaks are preserved, although it does not appear to allow control of the indention of those lines.
vim-guru 12y ago
Why make yet another markup language without any real improvements to the widely adopted markdown? Curly-braces are usually used to bind data, so you actually loose a great advantage that markdown has with it's syntax. Let's improve markdown instead
rhythmvs 12y ago
Happy to read there is some interest in “Markdown 2.0” or “lightweight markup, next generation”. With adoption by big outlets like Github and StackOverflow, and dozens of static site generators built on plain text source files, marked-up in Markdown syntax, Markdown is becoming a _de facto_ general-purpose document _editing_ and _storage_ standard. With the advent of fast client-side parsers, soon it might even substitute html as a document _exchange format_, too (at least for some use cases). 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/ http://blog.codinghorror.com/the-future-of-markdown/ ² https://github.com/rhythmus/markdown-resources https://github.com/rhythmus/markdown-resources ³ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not... ⁴ https://medium.com/the-future-of-publishing/495ccfe24a52 https://medium.com/the-future-of-publishing/495ccfe24a52 ⁵ http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-big-questions-that-the-markdown-spec-does-not-answer http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-... ⁶ http://fountain.io http://fountain.io ⁷ SkrivML ⁸ https://github.com/jakwings/strictdown https://github.com/jakwings/strictdown ⁹ http://www.z-m-l.com http://www.z-m-l.com ¹⁰ https://github.com/rhythmus/markdown-resources/blob/master/lightweightMarkupSyntaxComparison.tsv https://github.com/rhythmus/markdown-resources/blob/master/l...
bohwaz 12y ago
There's also an alternative lightweight implementation: http://bohwaz.net/p/SkrivLite-a-lightweight-implementation-of-SkrivML http://bohwaz.net/p/SkrivLite-a-lightweight-implementation-o...
naranja 12y ago
Oh no! Please not _another_ lightweight markup language. This increased diversity will only push Markdown's dominance and not help to get better alternatives _at all!_
- NaNaN 12y ago
  That is not just for Markdown at all, and Markdown is not good for everyone at all. Why so serious?

41 points by rhythmvs 12y ago

This seems like a more verbose version of Markdown :\ Maybe the only advantage is displaying code, but everything else is either equal to or more verbose than Markdown. EDIT: I do like the link syntax, though.

orclev 12y ago
Yeah, that was basically my reaction as well. They tweaked Markdown a bit, changed a few things around, but it's pretty much identical to Markdown. I don't really see any big wins here. This XKCD seems somewhat appropriate: http://xkcd.com/927/ http://xkcd.com/927/
- handyman5 12y ago
  Is it sad that I recognized the comic from the context and the number in the link?
  - thegeomaster 12y ago
    Just happened to me. The second I clicked it I figured out which one it was.
  - boomlinde 12y ago
    Sad but not very surprising: https://hn.algolia.com/?q=http%3A%2F%2Fxkcd.com%2F927#!/comment/forever/0/http%3A%2F%2Fxkcd.com%2F927 https://hn.algolia.com/?q=http%3A%2F%2Fxkcd.com%2F927#!/comm...
- NaNaN 12y ago
  You should be happy that it is not named Yet Another Markdown Language. And I don't think there will be a standard Markdown in front of the people who shout out HOLY MARKDOWN until John Gruber release an update.
smilekzs 12y ago
"Verbose" seems to be a trade-off for removal of intrinsic ambiguity (and the resulting standard wars) within markdown, which I speculate as the reason we still haven't come up with one "standard markdown" despite many calling for it. IMHO this took minimal yet established markups from various wiki and markdown-ish syntaxes, further simplified them, finally approaching what we wanted as a "standard markdown" in the first place.

norswap 12y ago

Criticism: - 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!

pandatigox 12y ago
I agree with you on the line returns. It really annoys me when it's not rendered like a WYSIWYG. Especially when I'm quoting or writing something like a poem. Nevertheless, I quite like how CSS classes fit nicely into the syntax
- JasonFruit 12y ago
  If I read it right, you're actually disagreeing.
krbbltr 12y ago
Yeah, the line breaks ruin it for me. I don't understand the point of it, either. Poems and the like could easily be handled by a special mode, similar to code blocks. Are there other situations where forced newlines would be useful? There may be, but I can't think of any. Either way, severely restricting how text – source code – can be organized just to simplify some rare special cases seems like a bad idea. It's a shame, since the rest of it looks really nice.

demetrius 12y ago

I hate '' for italic. It is strange from semantic point of view (I definitely don’t agree with the "its syntax is intuitive" claim), and it would force me to change the keyboard when I’m writing in Russian.

gfv 12y ago
Doesn't Russian use angular quotes or double quotes where angular ones are not available?

smilekzs 12y ago

Despite the negative tone here, I feel like the direction they're working towards. 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).

thegeomaster 12y ago

It looks nice, but do we really need another one of these?

NaNaN 12y ago
Better than just seeing Markdown/reStructuredText/AsciiDoc/Textile/... there. I'm designing a new markup language, too. Happy to draw inspiration from Skriv. Not all markup languages are good for blogging, especially for different spoken languages. At least, both Markdown and reStructuredText are not very good for Chinese writings.
- akurtzhs 12y ago
  What problems do Chinese writers run into when using Markdown or reStructuredText?
  - NaNaN 12y ago
    Most inline markups require spaces surrounding the text, and Chinese do not need spaces between words. Although reST provide "\ " to remove the spaces from output, it makes the document ugly.

coderdude 12y ago

I like how images are written: {{/path/to/img.png}} vs. Markdown's ![](/path/to/img.png) 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.

ilaksh 12y ago
Can we just make a new version of Markdown that supports that and Skriv | http://skriv.org http://skriv.org for links?
- coderdude 12y ago
  Skrivdown? :) You'd have to switch to Skriv's syntax for headers since Markdown's headers and Skriv's ordered lists use the same syntax. Another thing I'd change about Markdown would be to remove multiple syntaxes for writing the same element. For example, with Markdown you can use *, -, or + to create unordered lists. That might exist for some reason I don't know about but I don't like it.

userbinator 12y ago

These markups can affect full-words only, they are not effective if they are written in the middle of a word. 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.

fernly 12y ago
As in documenting an API or command syntax, when you want to go from mono (literal) to italic (variable input) with no break. In Skriv it would be ##--input=##''filename'' except that (a) Skriv requires a space and even if it didn't, (b) the -- would be an unbalanced strikeout code. Not to worry, reST doesn't do it either.

paulyg 12y ago

I jump between Creole and Markdown and this seems like an interesting mashup. Though I don't like all the choices made. I have been thinking lately about just combining Creole and Markdown into one master markup lang. 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.

fernly 12y ago

I've been comparing these things (ascii markups) lately, mainly because I'm writing software to support an organization with a long history using not one, not two, but three unique ascii markup conventions. Could these somehow be translated into a more or less standard one, and gain the freedom of output provided by e.g. Pandoc? 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 http://carl-sandburg.com/chicago.htm [2] http://www.shakespeare-online.com/plays/macbeth_3_1.html 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!

anon4 12y ago
It's a TABLE! I believe that's because it's a table semantically. I mean, look at it - three columns, fixed width, sometimes columns 1 and 2 merge together. That's a table any way you look at it. I never understood people's fear of tables - they're awesome, they're easy to control the lay out of, browsers support them just fine, they can be as flexible as you want. And if you feel sick every time when you type a <table> tag, you can specify them in CSS nowadays.

estebanrules 12y ago

I like the syntax. However, how many markup/markdown languages do we need?

OliverD 12y ago

I would change ''italic'' to italic. It is easier to remember how to create a bold and an italic word if you only have to remember one sign. Besides the ' sign is not very common in some countries.

MarcScott 12y ago

I've yet to find any markup language that has the power and flexibility of org-mode. 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.

fernly 12y ago
Thanks for pointing out YALML (lightweight markup language) for my collection! With regard to my comment below, I note that Org does support a Centered mode for paragraphs and a Verse mode in which line breaks are preserved, although it does not appear to allow control of the indention of those lines.

vim-guru 12y ago

Why make yet another markup language without any real improvements to the widely adopted markdown? Curly-braces are usually used to bind data, so you actually loose a great advantage that markdown has with it's syntax. Let's improve markdown instead

rhythmvs 12y ago

Happy to read there is some interest in “Markdown 2.0” or “lightweight markup, next generation”. With adoption by big outlets like Github and StackOverflow, and dozens of static site generators built on plain text source files, marked-up in Markdown syntax, Markdown is becoming a _de facto_ general-purpose document _editing_ and _storage_ standard. With the advent of fast client-side parsers, soon it might even substitute html as a document _exchange format_, too (at least for some use cases). 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/ http://blog.codinghorror.com/the-future-of-markdown/ ² https://github.com/rhythmus/markdown-resources https://github.com/rhythmus/markdown-resources ³ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/ http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not... ⁴ https://medium.com/the-future-of-publishing/495ccfe24a52 https://medium.com/the-future-of-publishing/495ccfe24a52 ⁵ http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-big-questions-that-the-markdown-spec-does-not-answer http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-... ⁶ http://fountain.io http://fountain.io ⁷ SkrivML ⁸ https://github.com/jakwings/strictdown https://github.com/jakwings/strictdown ⁹ http://www.z-m-l.com http://www.z-m-l.com ¹⁰ https://github.com/rhythmus/markdown-resources/blob/master/lightweightMarkupSyntaxComparison.tsv https://github.com/rhythmus/markdown-resources/blob/master/l...

bohwaz 12y ago

There's also an alternative lightweight implementation: http://bohwaz.net/p/SkrivLite-a-lightweight-implementation-of-SkrivML http://bohwaz.net/p/SkrivLite-a-lightweight-implementation-o...

naranja 12y ago

Oh no! Please not _another_ lightweight markup language. This increased diversity will only push Markdown's dominance and not help to get better alternatives _at all!_

NaNaN 12y ago
That is not just for Markdown at all, and Markdown is not good for everyone at all. Why so serious?