
Standard Markdown - hglaser
http://standardmarkdown.com/
======
bpierre
This is really great, but I don’t understand why everything has been made
privately. Following the first post [1], people were waiting for a move, and
as far as I know, it was a complete silence during two years, not even a “we
are working on it”.

A Markdown Community Group [2] has been created on w3.org, and people have
started to push some effort in it [3][4][5], but it has been totally ignored
since the beginning, despite the communication attempts.

Maybe I don’t have all the informations, but it looks like a waste to me, and
I find it disrespectful for the people who worked on the project. All of this
could have easily been avoided with a simple communication about the status of
the project.

[1] [http://blog.codinghorror.com/the-future-of-
markdown/](http://blog.codinghorror.com/the-future-of-markdown/)

[2]
[http://www.w3.org/community/markdown/](http://www.w3.org/community/markdown/)

[3]
[http://www.w3.org/community/markdown/wiki/Main_Page](http://www.w3.org/community/markdown/wiki/Main_Page)

[4] [http://lists.w3.org/Archives/Public/public-
markdown/2014Mar/...](http://lists.w3.org/Archives/Public/public-
markdown/2014Mar/0000.html)

[5] [http://lists.w3.org/Archives/Public/public-
markdown/2014Jul/...](http://lists.w3.org/Archives/Public/public-
markdown/2014Jul/0002.html)

~~~
TazeTSchnitzel
They've also unfairly appropriated the name "Markdown" and declared it
"Standard", which Gruber is (rightly) not too happy with.[0][1]

[0]
[https://twitter.com/justin/status/507304506007515136](https://twitter.com/justin/status/507304506007515136)

[1]
[https://twitter.com/markdown/status/507341395137658880](https://twitter.com/markdown/status/507341395137658880)

~~~
sjwright
There was an obvious, demonstrable need out there for implementation
consistency. Gruber didn't step up to help resolve confusions, so he has no
right to complain when other people do the hard work.

~~~
ebbv
That's an argument in favor of them making a spec, not an argument in favor of
them using the name "Standard Markdown."

They could have called it any number of other things that don't make the same
claims that "Standard Markdown" does. Off the top of my head; Common Markdown,
Clean Markdown, or better yet don't actually use the Markdown name, simply
imply it such as Forkdown or Sporkdown.

~~~
mendort
Maybe they can call it "Standardized Markdown" which would be both more
descriptive and accurate.

~~~
ebbv
That doesn't really address the main objection to the name "Standard Markdown"
unless you already know what the problem with the name is (and thus the
implications of the slight difference.)

It would be best if the team would just go another route entirely.

To be honest, I think this industry wide devotion to Markdown is hilarious,
since to me it's a pretty garbage way of solving an easily solved problem. The
main/only thing in its favor is its ubiquity.

~~~
jjoelson
What percentage of all Markdown written is on GitHub, Reddit, or Stack
Exchange? What percentage of rendered Markdown served to users is from those
sites? Tough to estimate, but I would say it's certainly a majority. Surely
any flavor of Markdown agreed upon by those sites can make a pretty strong
case to be considered "standard."

Out of curiosity, what do you think is the better "easy" solution to the
problem Markdown is trying to solve?

------
peterkelly
Is there a formal grammar defined? I don't see one here. They mention peg-
markdown which does use a formal grammar - or at least, multimarkdown does,
which is the one I've looked at.

Here's the link to MultiMarkdown's grammar:

[https://github.com/fletcher/MultiMarkdown-4/blob/master/pars...](https://github.com/fletcher/MultiMarkdown-4/blob/master/parser.leg)

It's littered with implementation code, but with this stripped out it would
make a good basis from which people can write parser generators from (that
don't depend on the specific implementation details of MultiMarkdown's
internal representation).

As far as I'm concerned, a formal definition should be an absolute requirement
for any official spec. The "spec" as presented simply looks like a large
collection of examples, informally specified in prose.

What's really needed is a grammar you can use for parser generators,
corresponding to a schema for an object model.

It's late here, I may have missed something, so feel free to correct me if if
this is the case ;)

~~~
dj-wonk
So, to summarize, we have a new standard with the name "Standard" in it
_without_ a formal grammar definition. Oops.

Unit tests are not enough.

~~~
dj-wonk
Here is a thread titled "Standard Markdown Formal Grammar":
[http://talk.standardmarkdown.com/t/standard-markdown-
formal-...](http://talk.standardmarkdown.com/t/standard-markdown-formal-
grammar/46/5)

------
ChuckMcM
Nicely done, and needed! But pretty much everyone I know who has used markdown
has wandered into the swamp that is known as 'tables of despair'.

Michael Fortin's syntax is pretty useful and quite close to the spirit of
Gruber's original efforts. (who hasn't done ascii tables with | and - right?)
Until tables are 'standard' I do not hold out a lot of hope for widespread
adoption.

That said, I really love taking it Markdown to this next level. And am
moderately amused by the recurrence of the themes over time. I'm a old RUNOFF
user from back in the day.

~~~
hayksaakian
I'm actually kind of happy that tables are complex

With the use cases for markdown, table seem inappropriate.

What I mean: tables are good at representing arbitrary data, particularly sets
of data stored somewhere.

Maybe it would be better to simply describe the data with json embedded in
markdown and delegate representation to something else.

~~~
ChuckMcM
The counter argument is that simple tables are simple. And as silly as that
sounds, a typical expository essay might easily include a 2 x 2 'table' to
explain some principle (I call them McKenzie tables since every presentation
from those guys seemed to include one or more). Or simple columnar data like
the current price of the Macbook pro line, or any number of things that are
represented easily and efficiently in a simple table. That is why I like
Fortin's syntax something like:

    
    
       | widgets  | quality level | cut-off point
       | :------- | :-----------  | :------------
       | frobs    | 98%           | 90%
       | bolts    | **65%**       | 70%
       | splangs  | 85%           | 80%
    

Reads easily in text and markdown's easily as well using multimarkdown (my
current go to implementation). Use your CSS to style the selectors tbody,
thead, and colgroup and you're off to the races.

~~~
thinkpad20
The problem that I see with that is it makes editing a table very difficult.
Sure, if you know exactly what you're going to put in a table, then it might
be worth it to draw all of those lines, but as soon as you need to go and edit
the content of a cell, or remove a column or something, you might have to go
and edit unrelated parts to maintain your formatting. It also seems like it'd
be a real pain to parse. I'm not sure I know of a better solution, except to
suggest that markdown might not really be suited for tables, and it's better
to just use HTML for that part.

~~~
mjhoy
Not quite related, but if you haven't seen how emacs and org-mode handle ascii
tables, it's pretty amazing! It will reflow automatically, and tabbing works
just like you would expect in a spreadsheet application.

------
saosebastiao
I'm super excited that JGM (of Pandoc) is heading this and has some
cooperation from Github and Reddit (both the largest users of Markdown that
I'm familiar with). This is something I've hoped to happen for a long time.

~~~
masklinn
> Github and Reddit (both the largest users of Markdown that I'm familiar
> with).

StackOverflow? (who're also on board via Atwood)

~~~
mark-r
Atwood hasn't been associated with StackOverflow for over 2 years:
[http://blog.codinghorror.com/farewell-stack-
exchange/](http://blog.codinghorror.com/farewell-stack-exchange/)

That said I'm sure he has valuable experience with Markdown and is almost
certainly using it again in his latest venture.

~~~
codinghorror
Ben is listed on the site and works at Stack Exchange right now.

------
pessimizer
How about a minimal set of asciidoc markup that gives people whatever warm
feeling they get out of markdown, but has the benefit of being pretty
consistently specified, allowing you to set variables (like multimarkdown),
and allowing you to create finished documents in the same style in which you
created your scratch documents?

[http://powerman.name/doc/asciidoc-
compact.html](http://powerman.name/doc/asciidoc-compact.html)

I'm probably tone-deaf on something here, because I simply don't understand
the appeal of the format.

edit - asciidoc talk:
[https://plus.google.com/114112334290393746697/posts/CdXJt6hV...](https://plus.google.com/114112334290393746697/posts/CdXJt6hVn5A)

~~~
jacquesm
The appeal is twofold: a lot of engines now understand it and it is
(relatively) easy to write by hand. (Except for the bloody links, writing the
HTML for them is _much_ easier than the equivalent markdown, I do it
infrequently enough that I always mix up the brackets or the order (or
both...).)

~~~
pessimizer
I understand the herd effect - so I put it in user-facing projects that I'm
working on - but I don't understand what's driving the herd. Specifically, I
don't see any advantages over asciidoc and find it awful to work with.

edit: I do understand this project, though. It'll get rid of the horribleness
in implementing markdown, at least.

~~~
derefr
> I don't see any advantages over asciidoc

Reddit uses Markdown. GitHub uses Markdown. HN (sorta) uses Markdown.
Wordpress, Tumblr, and Discourse all use Markdown. If I used Markdown for my
own User-Generated-Content Textareas™, people might _already know it_.

If I use Asciidoc, I may as well be using SGML. It's just another (nice!)
syntax you're forcing people to cram into their brains.

------
jader201
Gruber's first (that I know of) public response to this:

[https://twitter.com/gruber/status/507305771265454080](https://twitter.com/gruber/status/507305771265454080)

~~~
tizzdogg
Gruber also mentioned it recently on one of his talk show episodes. I cant
remember which episode, but as I recall he was not a fan of the effort at all
and thinks it is not necessary.

~~~
DonnyV
The question should be why does he feel so threatened by this? Its because its
a flushed out better "standard" version that everyone will use. Let the best
version win.

~~~
chipotle_coyote
I'd say "annoyed" rather than "threatened," and I think it's in part the name,
yes. I see a lot of "naming variants '$foo Markdown' is common, what's the
beef" responses and I get that, but _Standard_ has very different connotations
from _Multi-_ or _Github-Flavored_ or other past versions. I'm not sure that
simply naming it something else would have solved this issue, but I don't
think it would have hurt to pick something more like "Formal Markdown" \--
which captures the notion that you're trying make _a_ formalized standard
without explicitly saying "this is _the_ standard."

But I suspect it's also in part simply that Atwood and company never said in
public "we are doing this." They just announced it as a fait accompli. Yes,
two years ago Atwood and Gruber tweeted at one another briefly and Gruber said
he wasn't interested in formalizing the spec. But that's not _really_ an
attempt at having a discussion, and it sure as hell isn't an announcement of a
project.

I think a formalized spec for Markdown is a good thing. But the way this was
handled was still kind of a dick move, and I don't think it had to have been.

------
edavis
It's amazing how similar this is already to the RSS/Atom format wars:

Widely read blogger independently develops a simple file specification that
addresses a real world problem. Simple file format becomes a _de facto_
standard. Developers gripe about ambiguities in the specification. Effort to
create a formal, standardized specification is launched. This new effort is
publicly denounced by the original specification author.

------
kuon
I don't really see the point of this. Being vague is one of the biggest
strength of Markdown.

Markdown is being used by very different products to fulfill different
requirements. Having no specification means you can inspire yourself from
Markdown and just do your own thing, which is what is relevant.

Markdown is being used by comments systems, issue trackers, documentation
programs. Those have very different needs, and having a liberal non-
specification is what helped Markdown to be popular.

Coming with a new standard, not called "Standard Markdown" (which I think is
very presumptuous, even for a big company) and providing new features
(arranging/aligning images, variables, include, mathematic notation...) would
have been much more productive.

I mean, who cares of those little differences? When I edit a comment or
something, I just hit the preview button (or see the preview real time). I'm
not going to learn a specification, and if markdown has to look different on
stackoverflow or github or <insert doc system>, so be it.

Markdown is also mean for people who have no idea what a "syntax error" is, I
know the specification is meant for implementations, good, but if I want to
write an implementation, I want it to be fast and this kind of complicated
spec is exactly what prevent me from writing something lighting fast.

I'm really sorry, I don't want to insult your work (which is great), but it
looks like a waste of energy to me.

~~~
SoftwareMaven
Except it sucks when I have to go to the docs for the 10 different flavors of
markdown 10 different sites I go to use (assuming they have docs). I also have
to spend time documenting my own site when I incorporate markdown.pl versus
markdown.py versus some other markdown implementation.

Markdown has become popular enough that a complete, unambiguous spec is good
for end-users. If you are building a little text entry thing for your mp3
catalog app, sure, it's nothing to worry about. But when you are github and
stackoverflow and google, and end-users are authoring documents, _knowing_ the
behavior matters.

~~~
kuon
Yeah, but it doesn't define how markdown will be rendered.

For example, on github, to get a decent paragraph title, I must use #### (h4),
on some other site that might be h1 or h2 to get the effect I want.

I understand the need to define the grammar precisely, but for me Markdown is
highly tighten to the site it will be rendered to.

I'm not against a specification, but I feel this is a lot of work (and again
I'm not saying it's badly done) that feels unnecessary.

Taking your google example, they might deviate from the syntax because their
comment box is too small. I really don't want to argue, it's just some
feeling, it might not be rational, and by all means I'm not saying I'm right.
I was expecting (and waiting for) specifications for tons of things, but not
markdown.

------
buro9
I'm finding some bits odd.

Such as this: [http://jgm.github.io/stmd/spec.html#html-
blocks](http://jgm.github.io/stmd/spec.html#html-blocks)

The tags listed are not a complete list of section elements (missing `address`
and `nav`), nor the grouping elements (missing `main`), nor the embedded
content elements (missing `area`, `audio`, `iframe`, `img`, `param`,
`picture`, `source`, and `track`), and doesn't scratch the form elements (but
yet the "HTML blocks" include `form`, `fieldset`, `textarea` and `progress`).

The tags listed also include child elements, rather than just the topmost
parent elements that were listed in the original Markdown syntax:
[http://daringfireball.net/projects/markdown/syntax#html](http://daringfireball.net/projects/markdown/syntax#html)

So we have a list of arbitrary HTML elements that have been declared as "HTML
blocks", some of these are not really "blocks", and some are clearly other
things, and some things that perhaps should be included are not.

And reading through why this list exists creates a sense that the
implementation difficulty (of having to produce a balanced tree) is dictating
how Markdown must now be experienced by the users.

Example 99 is a great example of surprising a user by not doing what they
think will happen and leaving them with a game of "Guess why it's not
working.".

[http://jgm.github.io/stmd/spec.html#example-99](http://jgm.github.io/stmd/spec.html#example-99)

~~~
buro9
It's dawned on me why this is the case.

Gruber's Markdown has this goal:
[http://daringfireball.net/projects/markdown/syntax#philosoph...](http://daringfireball.net/projects/markdown/syntax#philosophy)

> Markdown is intended to be as easy-to-read and easy-to-write as is feasible.

That's it... that's the single big idea that drives the philosophy of
Markdown.

And how about Standard Markdown?
[http://standardmarkdown.com/#how](http://standardmarkdown.com/#how)

> one of our major goals is to make Markdown easier to parse, and to eliminate
> the many old inconsistencies and ambiguities that made writing a Markdown
> parser so difficult.

Markdown and Standard Markdown have very different goals.

One is designed to make it easy for end users to read and write content for
the web, the other is designed to make it easy for developers to parse and
process content for the web.

The purpose is no longer the same, a subtle shift has occurred.

~~~
Too
By fulfilling the second goal you make it easier for users to write the same
kind of markdown on different sites or copy-paste between sites, thus
fulfilling the first goal.

~~~
buro9
When it's decision time, one of those goals will override the other.

For a lot of cases it may be true that fulfilling the second fulfils the
first. But crucially, not for _all_ cases.

They are not equal goals, one does not fully imply the other (in either
direction). Yes, a better balance could be struck than today... but if the
second goal is trumping the first... the users will suffer.

------
loup-vaillant
This spec is not strict enough.

Okay, that came out wrong. While I understand why one would want _any_ input
to pass (web comment from non-technical users), I have experienced several
failures (wrong emphasis, missing link, weird unintended brackets…) just
because the original markdown.pl didn't warn me about some obvious mistake I
made.

We need a strict mode, where paragraphs cannot be interrupted, where fenced
code blocks must end by a fence (not just the end of the file), duplicate or
missing references must be signalled… That, and many other precautions could
turn Markdown into a serious and reliable document format.

Besides, this tolerance is complicating the grammar. I don't mind context
sensitivity nor ambiguity (parser generators can now deal with both), but I do
mind the sheer size. If you ask me, a formal spec (one that can be treated as
a DSL and translated mechanically into a parser), should not take more than
300 lines. More than that is probably too complicated to implement, or even
_use_.

------
pron
So it seems like this spec covers a minimum implementation, "basic" markdown.
I think extensions to (footnotes, tables, definition lists etc.) should also
be standardized, even if their implementation remains optional.

~~~
roryokane
On the discussion forum ([http://talk.standardmarkdown.com/t/the-inevitable-
markdownex...](http://talk.standardmarkdown.com/t/the-inevitable-
markdownextra-topic/42/8?u=roryokane)), a project lead said they are leaving
that for later:

> Extensions can come later. This project has the limited goal of
> standardizing “core” markdown features. There’s plenty to worry about there
> before we go to extensions.

------
filmgirlcw
Yeah, I'm going to just go ahead and say that Fletcher's MMD has been my
"standard" for years. Yes, yes, Github flavored is fine. You can adapt it. But
since Gruber doesn't want to set a more specific "spec," I default to what I
grew up on. And in this case, the last 7 years of my life have been spent
writing 95% of everything I publish (keep in mind, this is how I make my
living) with MultiMarkdown.

A for effort though.

------
eslaught
I'm a little surprised at the level of negativity in the majority of the
comments here. I understand our cultural need for criticism here, but the
critics here have touched almost everything (and note that the most
insubstantial of claims have bubbled up to the top of the comments here):

    
    
        Naming [2] [5]
        Closed (initial) development [1]
        Lack of formal grammar [3]
        Lack of tables [4]
        Just use another format (e.g. asciidoc) [6]
        Ambiguity is a feature [7]
    

Can we please take a moment to appreciate the achievement here? As opposed to
fulfilling our own sense entitlement?

Markdown is a popular language with an ambiguous, poorly specified spec and
buggy default implementation (so buggy that the vast majority of Markdown
users have probably never used it, if they even know it exists). Now, we have
a much more well-specified English language spec that explicitly addresses the
challenges of the grammar, with a test suite that does a much better job of
covering the corner cases, and much better default implementations. These
improvements are by no means perfect, but they _are_ improvements.

Yes, we need a formal grammar. Yes, we need tables, and other features. Yes,
the naming is unfortunate, though frankly I don't feel sorry for Gruber given
that Atwood posted a public letter calling for change two years ago. Yes,
these are all issues. But it is an achievement nevertheless, and let's
celebrate that.

And then we can get back to work.

\----

More generally, I think we have issues with entitlement here on HN. Frankly,
we have no fundamental right to either the original Markdown or this new
version. But when posts like this come up, we hack away at them as if we had a
right for better, as if the authors should be working to please us personally.
We need to stop acting like we have a right to sentence judgement over what
others release as open source.

[1]:
[https://news.ycombinator.com/item?id=8265469](https://news.ycombinator.com/item?id=8265469)

[2]:
[https://news.ycombinator.com/item?id=8266370](https://news.ycombinator.com/item?id=8266370)

[3]:
[https://news.ycombinator.com/item?id=8264828](https://news.ycombinator.com/item?id=8264828)

[4]:
[https://news.ycombinator.com/item?id=8265299](https://news.ycombinator.com/item?id=8265299)

[5]:
[https://news.ycombinator.com/item?id=8266073](https://news.ycombinator.com/item?id=8266073)

[6]:
[https://news.ycombinator.com/item?id=8264895](https://news.ycombinator.com/item?id=8264895)

[7]:
[https://news.ycombinator.com/item?id=8266121](https://news.ycombinator.com/item?id=8266121)

~~~
roop
The problem is that there's no formal grammar and the spec of "Standard
Markdown", while being more specific than John Gruber's, is still full of
ambiguities.

Some examples of ambiguities:

1\. It does not specify precedence. For example, if a line like "~~~" (or
"[ref]: /url") is followed by a setext underline, is that a header, or is that
the start of a fenced code block (or ref definition)?

2\. The spec says: "Code span backticks have higher precedence than any other
inline constructs except HTML tags and autolinks". It says as an example that
"<a href="`">`" is a HTML tag. What happens for different placement of
backticks, like "<a `href=""`>" or even "`<a href="">`" is left unspecified.

3\. What is the precedence or associativity of span-level constructs? For
example, does "<asterisk>a[b<asterisk>](url)" result in "a[b" being emphasised
or "b<asterisk>" being linked?

Thing is, a specification-by-example like this would have to keep an ever-
growing list of corner cases and give examples for each of them. To get
completely unambiguous, the list needs to be very long, and when it gets very
long, it becomes unwieldy to handle for an implementer of the spec.

Hence the need for a formal grammar, which is the shortest way of expressing
something unambiguously. But it's not possible to write a CFG for Markdown
because of Markdown's requirement that anything is valid input. So the next
best thing is to define a parsing algorithm, like the HTML5 spec. (Shameless
plug: vfmd ([http://www.vfmd.org/](http://www.vfmd.org/)) is one such Markdown
spec which specifies an unambiguous way to parse Markdown, with tests and a
reference implementation.)

So if "Standard Markdown" is NOT unambiguous and wouldn't be, then it's not a
"standard", so calling it "Standard Markdown" is not quite proper.

~~~
tuananh
well, they are working on it. Rome wasn't built in a day.

~~~
drostie
I mean, they've explicitly disclaimed that this is version 1.0, but they've
also explicitly claimed that this is complete, which it doesn't seem to me.
This spec is extremely repetitive (0-3 spaces is okay, 4 spaces is too much)
and doesn't actually follow a "top-down" approach which would resolve things
like precedence. What they've released is something more like a testing suite.

Even more troubling, they skipped the chance for some basic innovations which
will probably ultimately result in a Standard Markdown 2 spec. So, for
example, they are defining Markdown as a mapping to HTML, rather than a
mapping to an internal tree structure which can then be serialized to HTML.[1]
If you make that change in perspective, then you can have Markdown for other
languages too: not just HTML but also literate code in an arbitrary language,
for example.

Another innovation which should probably work its way into Markdown as it
becomes more of a file format is metadata. It's a little hard to remember, but
acceptable metadata tagging was one of the killer features of MP3s, leading
ultimately to their global rise. We don't have a good metadata expression for
text files, and Markdown's embedded link references are, essentially, a sort
of metadata already. Do this _before_ it gets to the W3C so that we can start
off a document with a simple

    
    
        @author: Chris Drost 
    

because once the W3C gets a hold of it that's likely to become something more
messy like:

    
    
        @author[http://www.w3.org/TR/markdown/2/] "Chris\u00a0Drost"
    

Another nice change would be an implementation-dependent $extra sigil$ for
inline text.[2] Some LaTeX math sites use Markdown with precisely this
extension for inline equations; it might be nice to say "this is mapped to a $
node, but the meaning of that is dependent on the tree-reader; the HTML reader
simply prepends and appends a literal dollar sign to the text without
embedding it in a tag."

[1] This isn't a huge change in the language but it's a huge change in
perspective. The main decision needed to fix this is to say that the "embedded
HTML blocks" should have a special sigil at the beginning which is not the <
character of the first tag; those "raw" blocks are then held separately in the
Markdown tree, and the serializer to HTML passes the raw blocks through
without HTML escaping or embedding in another tag.]

[2] Why not just use backticks? We could, of course. One problem here though
is that there is no good way to distinguish those literate-code blocks which
are commentary and those literate-code blocks which are code to be executed.
If you don't fix that now, it will probably be fixed in SM2.

------
01walid
How a group (of whoever they are) claim they're the standard about something
in nowadays without even caring about localization ?

2 years of 'complete specs' without a mention for RTL and how it should be
supported/written in markdown....

A bit disappointed tbh... even though it's a nice initiative...

~~~
Terr_
Since when does ASCII text support RTL?

I thought the whole point of Markdown was to define a mixed-mode formatting
that looked OK in ASCII and could be prettified in other contexts like HTML.

~~~
01walid
Since when Markdown was just about ASCII text ? then we can't write French,
Arabic, Chinese using markdown ?

my whole point is to define a syntax indication in the specs on how RTL
elements should be identified when converted to say HTML. when converted, THAT
element (or the whole document) would contains dir="RTL" attribute in its tag.

for example, something like this:

<-rtl--

Foo

Bar

would convert to:

<p dir="rtl">Foo

Bar

</p>

Prettifying won't help... RTL elements/document should be indicated in
markdown

~~~
obeid
I mentioned this on twitter to @defunkt
([https://twitter.com/_beid/status/507269600401440768](https://twitter.com/_beid/status/507269600401440768))

I don't agree that it should be defined in markdown, RTL languages should be
detected by the parser and be outputted within a block-level element, P is
good, with dir="rtl" as you mentioned.

~~~
ma2rten
actually you could just add dir="auto" and let the browser do the detection.

~~~
01walid
Please see my comment above...

------
vjeux
I modified the renderer to output React DOM instead of an HTML string if
anybody's interested

[https://github.com/vjeux/markdown-react](https://github.com/vjeux/markdown-
react)

------
smackfu
It seems like an obviously missing thing is a page that describes how users
should write markdown, in a few sentences. Otherwise you are just going to get
incorrect summaries of the spec.

You certainly can't point users to the spec, which is incredibly lengthy.

~~~
codinghorror
Good idea!

See: [http://talk.standardmarkdown.com/t/create-a-page-or-
subdomai...](http://talk.standardmarkdown.com/t/create-a-page-or-subdomain-
for-a-simple-users-guide/120)

------
phren0logy
The most surprising thing in here is the ire toward Gruber. Even if you
disagree with someone who writes a piece of software, they don't owe you
anything. You use and benefit from their work, and you are angry when they
don't agree with you? What a bunch of whiny, entitled nonsense.

Gruber has stated he wants to keep it ambiguous. You may disagree. But Gruber
owes you nothing, and you are in his debt if Markdown has been useful to you.
Draw inspiration from his project and make your own.

------
neya
This reminds me of a similar issue that happened within the Scala community.
David Polak, the creator of the Lift framework (which is used in production in
many top sites), had originally worked hard to create the framework (along
with others) and make it production worthy.

Later, he realized that the releases of the framework he had created were
happening without his involvement. But, instead of accusing the community, he
said something remarkable which only multiplied my original respect for him:

    
    
        I never "left" the Lift community. 
        Yes, I have other project and work in different languages. 
        What I did was cease to be Lift's benevolent dictator for life. 
        Lift has grown way beyond one person and the fact that
         the 2.5-M4 release was done without me is a strength, not a weakness.
    

[1]

Because, that's the spirit of open source. When you release something to the
public, for public consumption, then you must understand that someone is
eventually going to fork it up and assign it a different nomenclature,
sometimes even a nomenclature that you may not like. In this case, this
particular project had no standardization and a part of the community decided
to just standardized it. If you don't like this standardization, then simply
don't use it. Use what resonates with you. If you feel the standardization has
some flaws, then fork it and fix what's wrong. IF people agree with you,
eventually they will end up using your fork. It's as simple as that.

What is funny is to see John Gruber who appears to be butthurt about this,
when his contributions have grown negligent
([https://news.ycombinator.com/item?id=8266574](https://news.ycombinator.com/item?id=8266574)),
inconsistent and his recent focus has been more on other (personal) things.[2]

This reminds me of Luca Pasani[3], who released the much popular WURFL
repository as open source in a liberal license first, then one fine day, cried
foul because other people (including companies) were using it for profit (in
accordance with the license), deleted all online repositories and instances of
the project released under the old liberal license [4], then re-released the
project with a comparatively restrictive license.[5]

In my opinion, releasing something for open, public consumption means you have
to develop an honest mindset of accepting that other people WILL benefit from
your creation eventually. If you don't get that right, then open source is
probably isn't for you. (And crying foul later, is a double standard, if you
do)

[1] [http://stackoverflow.com/questions/12424617/comparing-
lift-w...](http://stackoverflow.com/questions/12424617/comparing-lift-with-
play2#comment20481903_12428316)

[2] like writing controversial Apple articles at daringfireball.

[3]
[http://en.wikipedia.org/wiki/Luca_Passani](http://en.wikipedia.org/wiki/Luca_Passani)

[4]
[http://en.wikipedia.org/wiki/WURFL#License_update](http://en.wikipedia.org/wiki/WURFL#License_update)

[5] [http://yro.slashdot.org/story/12/01/09/169216/wurfl-
founders...](http://yro.slashdot.org/story/12/01/09/169216/wurfl-founders-
fire-off-dmca-takedown-against-fork)

~~~
ulisesrmzroche
It's pretty much set in stone in the license.

"Neither the name “Markdown” nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior
written permission."

No ifs, and, or buts. It is what it is. It didn't meet that condition. It's in
breach of copyright.
[http://daringfireball.net/projects/markdown/license](http://daringfireball.net/projects/markdown/license)

~~~
philoushka
So John has an option to pursue legal action. Bring it on. I'm happy they're
forcing the issue.

Soon enough, no one will care. GH, SE and Reddit have enough mass to have
their flavour/spec dominate in terms of user base and adoption.

------
RubyPinch
it seems weird to have HTML as a non-optional part of the spec in two separate
locations, and then "Because we might be targeting a non-HTML format"

it would make more sense to just have some way to dedicate a block of text to
not be parsed in any form.

regardless, I'm 99% sure I'm intentionally missing the point here, as I can
imagine reddit's, github's, stackoverflow's, et al.'s implementations would
not support html tags at all (and anything for a personal site would have less
restrictions on usable html tags). So in practice, it is going to be optional
to some degree for implementers. but it seems weird to have that implied, when
the handling of info-lines for codeblocks is explicitly left ambiguous

------
jaredmcateer
Thanks, this has been long coming and sorely needed.

------
thomasfoster96
This sounds like a great idea in theory, but the execution seems to be a
little scratchy.

It sounds as though this is very much a unilateral decision from one of the
many sites that use Markdown to standardise it, masked by what seems to be a
call for other companies with an interest in Markdown to join.

It seems a little questionable to me for John Gruber to have been ignored in
this process. Afterall, he made Markdown and it probably would have been a
better idea to take his rather ambiguous spec, develop it into a proper
standard, and then call that version 1.0.

No doubt Jeff Atwood deserves some credit for trying to initiate a standards
process for Markdown, but I think he's doing it the wrong way.

~~~
frowaway001
> It seems a little questionable to me for John Gruber to have been ignored in
> this process.

No, it's the other way around. Gruber decided to ignore everyone who tried to
improve the sad state of Markdown for the last 10 years.

~~~
riking
And, if we look at the list of people who were writing it, we see Github,
Meteor, Reddit, and StackExchange people (plus JGM and Atwood) as the
participants, which I think cover the top 3 sites using Markdown.

And Jeff is using Markdown for his forum project, Discourse, so that's another
chunk of users.

This kind of coalition has the power of numbers to standardize on something,
which is why this is so exciting.

------
roryokane
There is a typo on the main page
[http://standardmarkdown.com/](http://standardmarkdown.com/), in the section
“How can I help?”:

“Read the spec, run the test suite, and exercise our reference
impementations.”

“impementations” → “implementations”

I couldn’t find a GitHub repository for the code of the website itself, or I
would have made a pull request.

Edit: I see there is already a thread about this:
[http://talk.standardmarkdown.com/t/site-typo-s-one-to-
start-...](http://talk.standardmarkdown.com/t/site-typo-s-one-to-start-
with/75)

------
Xeoncross
Wait, the spec doesn't even address things like tables.

~~~
masklinn
Because tables are implementation-specific extensions.

~~~
Falkon1313
So the standard does not provide a standard?

I find the dokuwiki table syntax to be pretty simple and effective, or the
markdown extra version. Don't know why none has been made a standard part of
markdown yet. Seems like it must be due to backlash against table-based web
designs of the 1990s, (which resulted in an entire generation of web
developers thinking that tables are inherently evil and an entire generation
of non-developers who just do things in MS Word or Excel instead because it's
relatively easy to make tables).

~~~
masklinn
> So the standard does not provide a standard?

A standard can be descriptive (bottom-up) or top-down (prescriptive). A
descriptive standard will only check and document common-ish features to
implementations. Tables are not one of them.

------
josegonzalez
+1. I hope that book publishing tools (leanpub for one) also subscribe to the
standard once it's been formalized/ported.

------
kennethfriedman
would love to hear Gruber's take on this.

~~~
phren0logy
He said in his podcast a few weeks ago that he thought it was unnecessary, as
the ambiguity allowed for different flavors with different uses. I'm assuming
the reference to the Yankees being the best team in baseball is directed at
Gruber.

During that podcast, Gruber encouraged that group to consider not calling what
they were doing Markdown. Something to the effect of, "Come up with your own
thing, and see if it catches on." He noted that the ambiguity is probably what
has made Markdown useful to such diverse groups with different needs, and
should be preserved.

~~~
smackfu
I remember listening, but wish I could find the episode again. Do you remember
which one it was?

~~~
philoushka
Listen to it on Overcast.fm

"Atwood's crusade"

[https://overcast.fm/podcasts/episode/344902019595#t=4527](https://overcast.fm/podcasts/episode/344902019595#t=4527)

~~~
canadev
I've landed on the guy's markdown pages (he refers to this in the podcast)
several times, trying to figure out how to do stuff in markdown. I find the
page hard to read (the font is tiny; I always resize it), and the examples
rarely seem to describe what I am trying to achieve.

------
archagon
This is an arrogant power play that's lost me a lot of respect for the
perpetrators. They clearly don't respect Gruber enough to honor his intent for
the language. And don't give me that "it's successful in spite of its
ambiguity" nonsense. A standard inevitably makes people find ways to work
"within the rules" while doing crazy stuff that the language is not intended
for (like many people in these comments). Markdown's lax specification ensures
that people honor the intent, not the implementation, and keeps it immediately
understandable and grokkable. Also, it's genericized? Are you kidding me?

They could have called it anything else, but they just had to go for full
ownership of the spec. I hope all the indie App Store developers that Gruber
is friends with shut this "standard" out.

------
reconbot
I think this is great, I'm all for extending markdown for specific situations
but I think the base h1, li, and p tags should be clearly defined. It appears
that most parsers could adopt most of the spec without breaking backwards
compatibility. (I'm probably wrong.)

There's an obvious annoyance with markdown like this, where a lack of a blank
line after the headlines causes problems but only in a few parsers. I'm glad
to see most of them do the right thing.

[http://johnmacfarlane.net/babelmark2/?normalize=1&text=%23+I...](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%23+I+love+this+stuff%0A%23%23+A+LOT!%0A-+li+1%0A-+li+2)!

------
aikah
Personally the first time I used markdown was when I signed up for SO.I used
to be a BBCode guy. But there are other formats, like rst.Strangely they are
not as popular,despite the fact that they have a spec.

~~~
lmm
rst is harder to write; it's as simple as that.

------
ilaksh
Does stackoverflow allow ```ruby now? I thought their thing was different.
There is a stackexchange person on this, so does that mean we will be able to
````mylanguage on stackoverflow sites?

~~~
buro9
There's nothing stopping you doing that already, it just might not pretty
print the output.

Most of us who syntax highlight code that is supplied in Markdown use Mike
Samuel's work: [https://google-code-
prettify.googlecode.com/svn/trunk/README...](https://google-code-
prettify.googlecode.com/svn/trunk/README.html)

Ruby isn't one of the languages presently supported, but if you add it then a
_lot_ of sites will start syntax highlighting Ruby.

~~~
ilaksh
Stack Overflow does syntax highlight Ruby its just a different syntax instead
of ``` its like <\-- language --> or something. At least thats what I
remember.

------
izietto
One extension I love is for HTML definition lists (I'm actually the author of
[this comment][0]). They are great for instance with changelogs; consider
this:

    
    
      ## ChangeLog
      
      1.0.2
      : Update README
      : Update of the script comment in order to reflect the README
      1.0.1
      : Fix minor bug
      1.0.0
    

[0] [http://talk.standardmarkdown.com/t/the-inevitable-
markdownex...](http://talk.standardmarkdown.com/t/the-inevitable-
markdownextra-topic/42/20?u=mdesantis)

------
thu
Cool, was wondering if John MacFarlane was part of it (and he is). The
standard implementation is in C[0]. I guess this is a good middle ground (from
a social perspective, not from a technical one). This is a very nice
initiative. In particular we can hope that all those markdown editors will be
perfectly compatible with each others, or that any deviation from the standard
will be very well approachable.

[0]: [https://github.com/jgm/stmd](https://github.com/jgm/stmd)

------
gregoire
On a related note, Marked and Ulysses (two applications that use Markdown)
recently launched TextBundle [0], a package file format that allows to include
the images referenced in a Markdown file with the Markdown file itself.

I would be interested in what the team behind Standard Markdown thinks about
this problem, it does not seem addressed in their spec (but it might be beyond
their scope).

[0]: [http://textbundle.org/](http://textbundle.org/)

------
Siecje
In the demo [http://jgm.github.io/stmd/js/](http://jgm.github.io/stmd/js/)

Why do <h3> tags have font-size: 100%?

~~~
matthiasv
It's because of this line:
[https://github.com/jgm/stmd/blob/e47d698c2cf1d24606bd2f708fe...](https://github.com/jgm/stmd/blob/e47d698c2cf1d24606bd2f708feed0c23a80ce79/js/index.html#L66)

But seriously, who cares?

~~~
Siecje
It breaks headings with '###'

~~~
matthiasv
But as long as the correct HTML is output it doesn't matter how it looks. I
mean that's the whole idea of separating structure from representation, right?

------
p8952
Your Discuss button seems to be overflowing:
[http://i.imgur.com/8s9O3DA.png](http://i.imgur.com/8s9O3DA.png)

~~~
ceejayoz
They're using a _very_ odd font stack.

font-family: 'Helvetica Neue', Helvetica, Arial, serif;

I've never seen serif used as the fallback for Helvetica/Arial.

~~~
codinghorror
Yeah I didn't notice that, let me fix!

Also: PRs welcome!

[http://talk.standardmarkdown.com/t/improvements-fixes-to-
the...](http://talk.standardmarkdown.com/t/improvements-fixes-to-the-
homepage/75)

------
gravicle
Here is my take on this: [http://spinhalf.net/omg-
markdown/](http://spinhalf.net/omg-markdown/)

------
esolyt
I don't think this is an attempt to claim ownership of Markdown, but it may
eventually turn out like that.

Why is Gruber not included in the group?

------
sherjilozair
A very useful addition to markdown would be the ability to put anchor links,
and "open in new tab" links. Both of these are not link defaults, but are
perfect examples of common cases that should work nicely.

Markdown is often used for one-page webpages due to its simplicity, and thus
anchor links become important in this usecase.

------
johnx123-up
Just for the sake of context [http://blog.codinghorror.com/standard-markdown-
is-now-common...](http://blog.codinghorror.com/standard-markdown-is-now-
common-markdown/) , project is now
[http://commonmark.org/](http://commonmark.org/)

------
stevekinney
It appears to me that this is a blatant violation of Markdown's license.

[https://github.com/jgm/stmd/issues/19](https://github.com/jgm/stmd/issues/19)

~~~
darkarmani
You mean this spec is violating the license of the software? I guess they
won't be able to distribute that software anymore?

Did you even read the start of that license?

> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met...

~~~
ulisesrmzroche
"Neither the name “Markdown” nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior
written permission."

[http://daringfireball.net/projects/markdown/license](http://daringfireball.net/projects/markdown/license)

~~~
darkarmani
That license only applies to the software. What happens when you have the
license revoked? You can't use the software anymore.

------
bachmeier
I don't see anything about math and in particular embedding equations via
MathJax. Is it considered unimportant or did I just miss it?

------
evv
So instead of simply removing HTML from markdown, this spec impossibly and
incorrectly attempts to include it. How frustrating..

------
mortdeus
Ooo, ooo I just thought of the cutuest name for this project.... xmarkdown!
Get it guys? You know like XHTML... Cute right?

------
igl
markdown is awesome! Why ruin it by design by committee? Standard Markdown
will go down as fascist markdown!

------
robotmlg
Relevant xkcd: [http://xkcd.com/927/](http://xkcd.com/927/)

~~~
alrs
Right now there aren't competing standards, there are competing ad-hoc
implementations.

------
pronoiac
If using that name seems rude, I suggest the name "MarkUp."

~~~
pimlottc
Markup is what HTML (and XML and SGML) is. Markdown was chosen as a response
to that.

I suppose they could just take a right turn and go for "MarkLeft" or
something...

~~~
josteink
MarkRight.

Markdown done right.

------
serencial
Honestly, I don't see the point of all the negative comments. If there's
something you can improve, why you can't do it? Even when big Markdown backers
are taking the lead. I guess what pissed Gruber is the naming stuff.

------
Fastidious
Markdown is dead. Long live kramdown! :-)

------
_pmf_
For a project that aims to replace a fluffy specification with a real
specification, this is not very good at all.

------
tomphoolery
upvoted because the test implementation is called a "dingus"

~~~
pbhjpbhj
The dingus could do with a mini reference so that new markdown users can trial
"standard markdown" without having to bring up a separate reference source
alongside it.

Default text would be good to, perhaps with a button for clearing the box.

------
phpnode
Next step W3C standard?

------
otikik
I like this. Kudos to everyone involved.

------
dang
Which post should we keep, this one or
[https://news.ycombinator.com/item?id=8264718](https://news.ycombinator.com/item?id=8264718),
which has the story?

Edit: since this thread has all the discussion, we'll keep this one.

~~~
sp332
So the voting buttons are just for decoration now? It's the number of comments
that determines which stories get the front page and which are buried?

~~~
dang
No, but in the case where there are two posts covering the same story on the
front page, it's certainly a factor.

If one url had been obviously better than the other, we would have kept it and
(if necessary) assigned it to the thread with more comments. In this case,
neither url was obviously better. That's why I asked, and also why the
responses were contradictory.

~~~
codinghorror
I'm fine with this one being the lead article.

p.s. my blog is awesome

------
happyscrappy
Atwood could have been more of an ass and called it Vanilla Markdown.

------
jamesrom
I never, ever, once have had a problem writing markdown on any website that
supports it.

This standard seems totally pointless.

~~~
recursive
I have had problems getting consistent output out of different "Markdown-
compatible" document tools. I hope this defragments the Markdown landscape.

------
moeedm
See, there you go again. Making shit complicated for no reason.

~~~
angersock
Try making a compliant parser without an unambiguous spec--these things are
"complicated" for a reason.

