Why CommonMark Isn't the Solution
ariabuckles.github.io
ariabuckles.github.io
All of this means that it is not possible to write a simple rule for when a paragraph (or other block element) ends.
Except there is a very simple rule, block elements are terminated with a blank line. The argument that changing
line 1
--- < this is inserted between two blocks
line 2
CM is a nice spec for a "markdown like system" :-) with many of the ambiguities rubbed off the edges. Add tables and I'll totally switch from multi-markdown to this more 'elucidated' specification.
I'm really surprised that so many people are hung up on Atwood et alia trying to bring some explicitness here. I've been using Markdown(tm) derived systems for a few years now and have felt the pain of many of their points directly.
Much of the frustration, at least from my eyes, is because CM attempts to incorporate too much of the mess that Md once introduced. I understand they did this in the interest of keeping compatibility with most "Markdown" documents. But they had the opportunity to fix things up, and really I wish they did.
The quintessential example here is the inclusion of HTML. By allowing html to be mixed in, Gruber really allowed a lot of flexibility and versatility, but that only makes sense if the content could be trusted and that it will only ever appear on the web. Tables are a great example of reasonable html usage- they are supported in both Md and CM. There are a lot more examples of unreasonable HTML usage, which I'd rather not enumerate.
These days, with the proliferation of Md as a widespread content language for public discussion across mediums, HTML doesn't belong. There are other cruft and ambiguities that CM could have cleaned up easily. CommonMark had the chance to improve this situation, but they went to great lengths to embrace it. If they had considered themselves as a distinct dialect instead of "the" standard, they may have gone a different route and written something more modern and clear.
From Atwood's announcement yesterday:
Edit: after a long and thoughtful email from John Gruber – which is greatly appreciated – he indicated that no form of the word "Markdown" is acceptable to him in this case. We are now using the name CommonMark. [2]
Anyway, the reason the specification is complicated is because creating a regular grammar from a rich irregular grammar requires a lot of work. Things like reading ahead to distinguish between:
paragraph 1
%%%
paragraph 2
paragraph 1
---
paragraph 2
The article is a case in point - StackOverflow can't be efficient if it's pushing an entire parser into the browser. It needs to degrade gracefully when javascript is off.
In general, the world will be better off when the canonical markdown documentation is not written with a tiny font on a grey background. Perhaps we'll even see markdown [or CommonMark] begin replacing RTF and BBCode more places.
[2]: http://blog.codinghorror.com/standard-markdown-is-now-common...
We used to think so."
In that case we may as well update the name in the HN title.
While I'm very supportive of some kind of sane Markdown specification, it's pretty disappointing that those with the biggest audience to push a specification have created such an apparently poor one. And after 2 years! Spec-by-examples, especially for an inherently ambiguous and forgiving syntax like Markdown, should be known to be a bad idea.
Fast-forward today: I've started to use Asciidoc with the Atom editor and its Asciidoc live preview. I'm using asciidoctor to generate docbook, and xslt to get it formatted in the way I want. I feel productive to write the content, and I can control every aspect of the output, in the very specific way I see fit.
A simple blog post with a bunch of paragraphs and bold styles may not be worth it, but anything more complex will favor asciidoc.
Not that it's not a good article - it is. But damn do I hate when people go about yelling "This isn't the solution! You're doing it wrong!". Urgh.
I wish Hacker News had markdown.
Off topic question: Why has rich text fallen so far out of fashion? I really like Markdown, but why is it that Markdown is now so popular and richtext boxes that can display a realtime preview (e.g. bolding text, italics, etc) aren't. What is it markdown offers over that? Is it just transportability?
I think GMail's is pretty decent, but the majority of rich text editors I've used on the Internet over time have caused almost as many issues as they solve when trying to write formatted text.
One nice feature is that markdown makes text annotations explicit and obvious. There's no hidden styling. Empty lines don't have a font size. Its obvious when a bolded region doesn't bold the spaces between words. In the Rich Hickey[1] sense, markdown is much simpler than rich text editing because all you have to worry about is the semantics of your text (this is a heading) and not how its actually styled.
Weirdly, its kind of a huge throwback to LaTeX. Thinking of markdown as a "modern, simplified LaTeX for the web" seriously hits the mark.
It wasn't because the implementation was buggy but rather the fact the end-user thought it should behave like word and just copied/pasted stuff.
Rich text editors are more complicated and tend to have usability issues. I had to support one for a year with very, very average users who used the application infrequently.
So you're left with trampling over the input experience with a lot of javascript. It breaks things like the "it's all text" extension, and generally will only work for the subset of configurations that is tested for.
If browsers had decent html-editing widgets, it might work better. I've yet to see any form of rich text editing that doesn't lead to frustration (never mind works on mobile touch etc).
Google has an interesting solution for G+ -- they've broken plain text entry (and plain text paste of long texts) without giving any benefits of rich text entry. But I'm sure it's great if you live in a bubble where no-one's used an actual text editor, and gwt is the best set of widget anyone's heard of. Facebook on mobile (in a mobile web browser) is pretty awful too, if you try to use the completion-options for tagging friends.
Come to think of it, I'd only be half as upset with g+ if one could simply upload a utf-8 text file into all of the comment/edit boxes.
A very good question. I think it's because once you can type fast, having to take your hands off the keyboard to use the mouse to select text, apply various styles, add links, etc. is slower than just writing everything with the keyboard without raising your hands.
Plus, as others have pointed out, there's that 1/2 MB entry fee. Expensive on transit and on local resources.
Maybe also a correlation with the kinds of people who write nontrivial text on their mobile devices, and are comfortable with in-line markup?
Additionally, I think it emphasizes the styles that are important in social media (blockquotes, code, bold, and italics) while de-emphasizing those features that are less important to it. The rich text editors, even on the web, all have a standard layout of buttons which displays all the wrong features first.
[1] https://github.com/vfmd/vfmd-spec/commits/gh-pages?page=7 [2] http://blog.codinghorror.com/standard-markdown-is-now-common...
We've been working on the Standard Markdown project for about two years now.
As we got closer to being ready for public feedback, we emailed John Gruber,
the original creator of Markdown, two weeks ago (On August 19th, to be
precise) with a link to the Standard Markdown spec, asking him for his
feedback. Since John MacFarlane was the primary author of most of the work,
we suggested that he be the one to reach out.
We then waited two weeks for a response.
and again:
Starting with the name. In his email John graciously indicated that he would
"probably" approve a name like "Strict Markdown" or "Pedantic Markdown".
Given the very public earlier miscommunication about naming, that
consideration is appreciated.
We replied with the following suggestions:
Compatible Markdown
Regular Markdown
Community Markdown
Common Markdown
Uniform Markdown
Vanilla Markdown
We haven't heard back after replying last night, and I'm not sure we ever
will,What does surprise me is how Marco was happy to be one of Gruber's flying monkeys on Twitter. Maybe Marco has an interest in the fight that is unknown to me, dunno.
Anyway, I don't care one way or the other. If forced to care, I'd even side with Gruber on the principles. But don't be shocked that some parties handled this in a less than graceful manner.
Stay tuned though. My sources tell me he's going do a really clever thing with a dollar sign in the middle of "Microsoft" next week.
Maybe he has a good argument that they can't call their thing Markdown, but certainly if he starts whinging that they aren't properly capitalizing his trademark, then I think he's behaving in a hypocritical fashion when he quite clearly takes other people's trademarks so casually.
Also, I think it's just as childish as seeing Micro$oft back in the day, but I guess that's a matter of taste.
<script>
var CONTENT = '' +
"Why Common Markdown isn't the Solution\n" +
...
HTML documents are a pretty good choice for, y'know, HTML.
Well, if your goal was to increase the page weight from 10kB to 2.2Mb, you surely succeeded.
I suspect this pattern will continue into perpetuity because such a large audience will never come to grips with the fact that "better" isn't always better.
Sad.
RSS:Atom might, arguably. be very loosely analogous to Markdown :: Common Markdown.