SkrivML: A lightweight markup language

41 pointsby rhythmvsalmost 11 years ago

16 comments

fernlyalmost 11 years 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] <a href="http://carl-sandburg.com/chicago.htm" rel="nofollow">http://carl-sandburg.com/chicago.htm</a>[2] <a href="http://www.shakespeare-online.com/plays/macbeth_3_1.html" rel="nofollow">http://www.shakespeare-online.com/plays/macbeth_3_1.html</a> and this is a wretchedly ugly example but look at the source! It's a TABLE!

评论 #7788994 未加载

评论 #7788218 未加载

评论 #7790568 未加载

评论 #7788524 未加载

norswapalmost 11 years 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!

评论 #7787649 未加载

评论 #7787202 未加载

coderdudealmost 11 years 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.

评论 #7787779 未加载

demetriusalmost 11 years 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.

评论 #7787534 未加载

ultimatedelmanalmost 11 years 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.

评论 #7787072 未加载

评论 #7787240 未加载

thegeomasteralmost 11 years ago

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

评论 #7787348 未加载

paulygalmost 11 years 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.

userbinatoralmost 11 years 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.

评论 #7787790 未加载

MarcScottalmost 11 years 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.

评论 #7788100 未加载

smilekzsalmost 11 years 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).

vim-gurualmost 11 years 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

bohwazalmost 11 years ago

There's also an alternative lightweight implementation: <a href="http://bohwaz.net/p/SkrivLite-a-lightweight-implementation-of-SkrivML" rel="nofollow">http://bohwaz.net/p/SkrivLite-a-lightweight-implementation-o...</a>

OliverDalmost 11 years 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.

naranjaalmost 11 years 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!_

评论 #7790040 未加载

estebanrulesalmost 11 years ago

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

rhythmvsalmost 11 years 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.)¹ <a href="http://blog.codinghorror.com/the-future-of-markdown/" rel="nofollow">http://blog.codinghorror.com/the-future-of-markdown/</a> ² <a href="https://github.com/rhythmus/markdown-resources" rel="nofollow">https://github.com/rhythmus/markdown-resources</a> ³ <a href="http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/" rel="nofollow">http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not...</a> ⁴ <a href="https://medium.com/the-future-of-publishing/495ccfe24a52" rel="nofollow">https://medium.com/the-future-of-publishing/495ccfe24a52</a> ⁵ <a href="http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-big-questions-that-the-markdown-spec-does-not-answer" rel="nofollow">http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-...</a> ⁶ <a href="http://fountain.io" rel="nofollow">http://fountain.io</a> ⁷ SkrivML ⁸ <a href="https://github.com/jakwings/strictdown" rel="nofollow">https://github.com/jakwings/strictdown</a> ⁹ <a href="http://www.z-m-l.com" rel="nofollow">http://www.z-m-l.com</a> ¹⁰ <a href="https://github.com/rhythmus/markdown-resources/blob/master/lightweightMarkupSyntaxComparison.tsv" rel="nofollow">https://github.com/rhythmus/markdown-resources/blob/master/l...</a>

评论 #7788832 未加载