In the transition to Standard Markdown, it probably makes sense for existing parsers to have two modes:
Quirks Mode — for the way that parser used to behave (validated by something like Babelmark.
Standard Mode — for the new behaviors defined in the Standard Markdown spec and validated by the Standard Markdown test suite.
I just wonder if people will want the old behaviors from their parsers for older documents, as a stopgap?
So then the question is, how is this quirks mode triggered? Is it a flag in the document, or just a boolean you pass to the parser out of band? Maybe something in the UI that the user selects somewhere?
+++ codinghorror [Sep 03 14 18:36 ]:
In the transition to Standard Markdown, it probably makes sense for
existing parsers to have two modes:
* Quirks Mode — for the way that parser used to behave (validated by
something like Babelmark.
Which parser? The problem is that they all behave differently.
While we’re at it, we probably need a “strict mode” too. As it stands, this standard is nowhere strict enough for some purposes.
While I understand the need for a tolerant mode where nearly all input is accepted, (like internet comments), some other applications such as serious documentation, or static website generators, need something more stringent. I stopped counting the number of times I introduced errors such as wrong emphasis, links that don’t work… because of a silly error of mine, that a more strict parser could have caught.
We could forbid missing or redundant link labels. We could forbid paragraphs interruption. We could forbid fenced code blocks with no closing fence. Anywhere an easy mistake could corrupt the output should be looked at.
But isn’t the whole point of the standard that previously, there was no one way Markdown parsers worked? That everyone interpreted the original description differently? What exactly is a parser in quirks mode then supposed to do differently? Isn’t standard mode just another acceptable way a parser would behave under the old interpretion?
To me, a different mode and validation only makes sense once the standard introduces breaking changes from the status quo. But as far as I understood the whole Standard Markdown project, its primary purpose is to find a common ground of all the different parsers.
I suppose existing implementations are supposed to evolve, and match the standard. For instance, MultiMarkdown would fall down to the current MultiMarkdown in its quirks mode. Reddit and Git Hub would likewise have their own quirks mode.
This standard does introduce some breaking changes.
Well, as far as I can tell, all the breaking changes except the list thing are currently being discussed here.
Yes so each one would have a local Quirks mode that means “behave as I used to behave in the past”.
Strict is rather counter to the philosophy of Markdown, though, isn’t it?
Possibly, yes. As @loupvaillant noted there are a handful of breaking changes in the spec though they are chosen very judiciously and with the intent to break as little as possible in the least damaging ways.
Ah, now I get what you mean. Yeah, that makes sense for all existing parsers, if just to keep compatibility of existing documents.
However that exactly is what makes it different when trying to think about how to trigger it. Since we would want to keep the old documents to continue parsing correctly (in “quirks mode”), we would need a
<!DOCTYPE html> like thing to trigger standard mode, but that doesn’t really make sense in the context of Markdown.
So the better solution would probably to just have this either as a parser-wide setting (so that users can keep using the old syntax), or make the parser split up old and new documents in a different way. I don’t think it’s the job of Standard Markdown to enable such a thing at the syntax level though.
One of the things I’d warn against is adding quirks mode to the existing parser - it makes it harder for people that want/need to add features to the standard parser, because now we have to look at the quirks stuff as well. It’s mental clutter.
Out of band sounds like the best option, and already has precedent in kramdown, which has an option to take input as kramdown-flavored or github-flavored markdown. Unless there will be support in Standard Markdown for extensions/options in comments, it doesn’t make sense to have something in the document itself to specify the flavor.