Are Atwood et al. calling it "Standard Markdown" because they don't have enough of their own popularity, and feel the need to appropriate someone else's decade-old coolness in order to be recognized as significant people because they can't accomplish that in their own right?
Or are Atwood et al. calling it "Standard Markdown" because they know quite well that, given the massive proliferation of Markdown varieties all of which use the name "Markdown", naming it anything else essentially guarantees that because no one will ever hear of their effort, and therefore no developers will ever use their standardized variant, no matter how much less painful doing so would be for them and their users?
If they called it "Syntaxx, a flavor of Markdown that 9 organizations agree to support to enable text markup interop," that would be okay. Just like how "PerconaDB" is "PerconaDB, a mysql fork that's still protocol compatible with additional performance improvements."
> The words "Standard Markdown" sound like it is the standard from the owners of the Markdown.
"Standard X" sounds a lot more to me to be "what a an interested committee did to X after it became popular and multiple different implementations of X existed, quite likely with only a distant, if any, connection to the creator of X".
I mean, if someone says "Standard Pascal" or "Standard SQL", or "Standard HTML", I don't assume it came from the inventors of those technologies.
Except we are computer scientists and there is no BNF grammar (or what have you) for the language. We all know we can do better than that. I'm just shocked this omission went for so long without anyone noticing--it's a big freaking deal.
Formalization of a grammar isn't "design by committee" (and in any case, this work in particular certainly was not). Formalization sets a logical, mathematical foundation for something that has thus far been a rather back-of-the-napkin, cowboy coded, cargo cult kind of thing. Could you name all the terminals before? I couldn't.
Markdown is implemented in hundreds of places (conservative guess). Discounting marked deviations and well-known dialects, it is a nontrivial task to ascertain whether a given Markdown implementation will produce the "correct output". What is correct output? Our ability to express or ascertain that is complicated by the fact that some rather archaic perl code [1] somehow holds the dubious distinction of being the de facto standard reference point for Markdown. Perhaps it was chosen as such on account of being the first mover, but probably its because nobody else had spoken up yet. (We're playing catch up now.)
"Implementation defines the standard" is a poor substitute for formality and is the result of intellectual laziness. (Hello PHP prior to HHVM.)
How did any of us effectively communicate what we thought correct meant? I feel a lot of our consensus was arrived at by enumerating all the examples and complex edge cases we could think of. (There's an idea that'll cover all the bases, yet it still maintains the niceties of being wonderfully concise!)
A formal grammar, as it turns out, is rather usually concise by nature (at least for the types of languages we care to design). To the attentive and deliberate thinker, a grammar's rules can be beautiful. A random mental walk through a complex repeating parse tree fills the mind all at once with intracate patterns and possibility. These are structures you can truly grok. With just pen and paper, or a standard text editor, you can easily define how the edges and vertices of an arbitrarily complex, infinite graph can connect. It's really kind of special, and definitely cerebral.
So now that we have a Markdown grammar to look to, libraries now have an easy model for attaining consensus agreement.
Nobody is going to force anyone to change their current implementation or preference. If you like the one you've got, that's perfectly valid state to be in. If your only objection to the new formalization is because it was named the so-called "standard grammar," it's just a name. A silly old case of primate chest pounding, at that. Great ape problems.
Despite all the drama, this spec will probably not be the final end-all, be-all of 80 character wide expression. I can picture infinitely many such grammars, each one being just a little more absurdly named than its predecessor. Nothing is stopping you from forking "standard markdown" and calling it MarkyMark or something.
I still can't believe none of us ever noticed there wasn't a grammar for this. Especially given we communicated all of it through bloated Perl code shared from a zip file.
Has Gruber opined on Seibel's (IMHO good) idea? If he claims he'd be OK with "Common Markdown", I'll have to revise my opinion of him in a much more favorable direction. (And, amusingly, Common Lisp is itself a standard, so perhaps "Common Markdown" would be enough to satisfy everyone.)
If they called it "Syntaxx, [twenty more words that no one cares about]", no one will hear of it, and no one will use it. The words around "Markdown" might be negotiable; the presence of "Markdown" itself makes or breaks the viability of the project as a whole -- without that, Atwood et al. might as well not bother.
Are Atwood et al. calling it "Standard Markdown" because they don't have enough of their own popularity, and feel the need to appropriate someone else's decade-old coolness in order to be recognized as significant people because they can't accomplish that in their own right?
Or are Atwood et al. calling it "Standard Markdown" because they know quite well that, given the massive proliferation of Markdown varieties all of which use the name "Markdown", naming it anything else essentially guarantees that because no one will ever hear of their effort, and therefore no developers will ever use their standardized variant, no matter how much less painful doing so would be for them and their users?