From the spec:<p>> No double symbols, i.e. <i>strong</i> not *strong*.<p>I understand the rationale. <i>But,</i> this is immediately no longer Markdown. "It's 'Markdown, Refactored!'" If "refactored" means "incompatible," sure? I guess? But still: incompatible.<p>"So what?" Good question, imaginary interlocutor. Here's so what: one of Markdown's defining features, love or it hate it, is that it <i>deliberately</i> doesn't make you choose between emphasizing with * characters or emphasizing with _ characters, other than being consistent with the start and end. Use a single * or _ character, get emphasis/italics; use double, get strong/bold; you don't get underlines because you don't use those in typography.<p>The same is true for lists: only "-" is acceptable, not "+" or "<i>". Fine, but there are a lot of Markdown documents that are out there that use "</i>" as the list character, and I am sure there is at least one weirdo inexplicably using "+".<p>So StrictMark breaks <i>every</i> Markdown document that uses boldface, and probably about half the Markdown documents that use italics. (I don't know about other Markdown users, but over the years I have <i>not</i> been consistent with how I markup italics, for a variety of reasons.) And, it probably breaks about half the unordered lists in the wild, too.<p>I understand that this is being done for well-intentioned and noble reasons, but: it ain't Markdown. It's a new, incompatible plaintext markup system. This creates a bit of an uncomfortable point: if I'm going to have to redo all my documents (or just do things The New Way going forward), then why not switch to AsciiDoc or Textile?
Markdown was engineered to be flexible _on purpose_ because it was designed for writers and readers, not programmers.<p>Writers are less likely to care about what symbol means "bulleted list item", as long as anything that makes sense for it, just works.<p>It's a mistake to think of Markdown as a programming language, or a "formal grammar".<p>That being said, if it works for you go for it...
It's a good effort, but I'm afraid it isn't a good fit for me, three things stand out:<p>1) the use of # rather than underline for headings. That why I feel you loose the beauty of the source form - headers disappear visually without a smart editor - if you demand a smart/wysiwyg editor anyway... Might just use a sgml/xml/html subset.<p>2) one symbol references. This strikes me as overly limiting - why not alphanumeric string - or at the very least any number string? It feels a bit strange to be forced to count 1,2...9,a - and not be able to things like a1, a2, b11.<p>3) "no way to put backticks inside a code span." So, no (full) examples of restricted markdown in codeblocks? Not to mention the many languages that use backticks?<p>I think you might be happier with reStructuredText than markdown: <a href="https://en.m.wikipedia.org/wiki/ReStructuredText" rel="nofollow">https://en.m.wikipedia.org/wiki/ReStructuredText</a>
At first glance, there's a lot of words and not many examples. It's hard to quickly see what's different and special about this version of Markdown, other than "it's a formal subset of the other formats".<p>I see some examples for specific elements, but I'd love to see "here's an example demonstrating the problem(s) this addresses", and "here's the fixed version of that example".<p>There could be sub-sections of contrasting examples, like in coding style guides, showing the Old/New (Bad/Good?) styles.
I don't even agree with all of the design but Thank Goodness for a regular grammar, domain specific syntax transclusion, and only one syntax per feature. Love it.
> Yes, HTML is a widely supported standard, but it is hopelessly elephantine. Let's think, who can afford to develop/support a proper HTML engine? That is roughly one-and-a-half companies in the world. Hence the interest in a minimalistic hypertext markup language.<p>There are <i>dozens</i> of proper HTML engines. Implementing a proper DOM and CSS is the hard part, which is why we have few full-featured browsers.
This won't work for my docs at all. I use all three unordered bullets to differentiate things in plaintext.<p>The opinionation that removes synonyms will kill any chances of this working with legacy IMO. Any significant doc base will hit myriad issues that come down to "I didn't like that form of it." I was initially OK with the idea of a parseable subset, which would be useful, but this goes too far with a "one way only" attitude. No thanks.<p>That said, someone should do what the project <i>claims</i> to do, without gutting the language. A formalized subset of CommonMark that only skips formally indescribable specs but otherwise preserves everything else would be useful in some situations. It might even become the defacto CommonMark spec if it's easier to implement.
> The unordered list markup symbol is a dash -. The other two Markdown options are * and +. But * is ambiguous and + is unpopular and there must be one way only!<p>THANK YOU for getting rid of the asterisk. As a former org-mode user it has always bugged me when people use the asterisk for lists, not headings. :)
I like it. I mean I'm not sure how much I agree with some of the specific design decisions, but it's such an improvement to lose the ambiguity.
Reference links as opposed to inline links is a huge plus, but like most others here I'm puzzled at the single-char restriction.<p>I tend to restructure documents often, writing things as they come into my head and moving pieces around to better convey my message. With named references, I can simply alphabetize them at the bottom and forget about them while I move sections around.<p>With single-char identifiers though, I'd feel an obligation to keep things in reference order, so one more thing to think about while I'm working.<p>On another note, I'm interested in this idea of reusing image links to preview CSVs and other formats. (graphviz comes to mind) Do you have any examples of this being used in a document and the tooling to stitch it together?
This is pointless. We can see the input and output:<p><a href="http://doc.replicated.cc/%5EWiki/strictmark.sm?@text" rel="nofollow">http://doc.replicated.cc/%5EWiki/strictmark.sm?@text</a><p><a href="http://doc.replicated.cc/%5EWiki/strictmark.sm" rel="nofollow">http://doc.replicated.cc/%5EWiki/strictmark.sm</a><p>So obviously an implementation was made, but whoever wrote the article didnt bother to share the implementation.
I appreciate all opinions as equally useless and this is just an opinionated less-usefull markdown.....I don't see the point at all....<p>markdown is meant for rendering .....<p>it should be as flexible as possible to write content....not restricted. I get the pain points of the devs ... never was the point of markdown. I feel like this engineers a new problem.... by removing an old solution