Hacker News Reader

Comment by verandaguy | Hacker News Reader

I'm actually kind of excited about this! A `text/markdown` MIME type could (maybe? hopefully?) pave the way for native content authoring in Markdown without having to use an HTML-targeting compiler between the author and the browser.

I might be being optimistic, but if that ever happens, it could be the start of a new era in internet content authorship!

View on HN

Which markdown? There are various variants out there and the original is unsuitable for more than a most basic web page.

The RFC for text/markdown includes a variant specifier but that only makes me think that we would be repeating the mistake of early browers when there were browser-specific HTML tags.

    Which markdown?

That depends on which one eventually gets specified (if at all) by some reputable standardization body. And sometimes, people don't want much more than a static web page!

Good point; we'd definitely need a standard. Thankfully, [CommonMark][1] has been in development a while now, and features a complete, unambiguous spec, reference implementation, and test suite.

A little more work on that to get it to version 1.0 and we'd be golden.

[1]: http://commonmark.org/

Is it really unambiguous? There is no grammar, but the spec describes things in English. It's really hard to avoid ambiguities and impossible to proof unambiguousness without formal methods.

I guess it's hard to say for sure that it's completely unambiguous, but that's definitely the intent. [The spec][1] even says:

> This document attempts to specify Markdown syntax unambiguously.

So if you're aware of any ambiguities in the spec, those are bugs which should be reported and fixed.

[1]: http://spec.commonmark.org/0.27/

You may want to work on specifying a formal grammar in EBNF or similiar.

Great for library / parser implementers and it helps discover ambiguities.

From John MacFarlane, the author of the CommonMark spec:

> If anyone wants to contribute a BNF, please do! But I'm very skeptical that it can be done, due to the many quirks of the syntax.

https://github.com/jgm/CommonMark/issues/113#issuecomment-60...

So it's basically as useless for general processing as Markdown, because you won't have a grammar from which you can generate parser, hence all the parsers will be handcoded with various quirks differing from one to another and none of which will produce a parse tree.

If it's hard to write a BNF, it's also hard to write a parser.

I'm baffled. Without a formal grammar CommonMark is useless. Who implements a parser without a formal grammar?

If the syntax has so many issues that you can't specify a formal grammar, there's a problem with the spec.

BNF doesn't make something unambiguous.

I mean, Foo = "hello" / "hello" is totally acceptable, and if you have any indirection like Foo = XXX / YYY with XXX, YYY = "hello" you can then attach different semantics to XXX and YYY despite it being ambiguous. Add in more levels of indirection, and you have a lower chance of it being trivially obvious.

But there exist tools to help you decide wether a grammar is unambiguous when you have a formal grammar: https://en.wikipedia.org/wiki/Ambiguous_grammar#Recognizing_...

http://vfmd.org has an exhaustive and unambiguous formal spec for (a variant of) Markdown. As a bonus, it's easy to understand, nicely extensible, and has an example implementation. The only drawback I'm aware of is that it seems routinely ignored by nearly everyone. I wonder why?

While the spec is way more formal, it's still not in a form that easily lends for a proof that it's unambiguous.

I have not looked into the details of the grammar, but proving that a grammar is unambiguous is typically done by proving that it is in, say, LL(1) or LR(1) (or some related family). This approach towards unambiguity has the additional advantage that it is easy to derive a parsing algporithm directly from the grammar that has nice theoretical properties (e.g. linear parsing time in the input length; where the hidden constant depends on the grammar).

There is no grammar, it's a description how to parse markdown using regexes.

What a great idea. This is exactly what we need.

I wonder if Markdown will ever get style annotations? Like CSS, but lighter and less broken.

What kind of style annotations? Markdown can already do bold, italic, and in some implementations, ~~strikethrough~~ and ^superscript.

Anything much more complicated than that I think risks jeopardizing Markdown's readability in plain text format and intuitive simplicity. Markdown is meant to be focused more on content than style.

I think XHTML shows that trying to create the specification first puts the cart before the horse.

Write software first; people will create content that matches the platforms that they care about most.

I wonder why VFMD (http://vfmd.org) isn't the choice among people picking a Markdown specification or parser? Well specified, unambiguous, easily extensible, with a reference implementation, open-source. I'd imagine it could be at least mentioned in the RFC?

Extremely interesting backstory from when Standard Markdown was announced: https://news.ycombinator.com/item?id=8264733

Basically a small group of people worked in private for years while there were public community efforts, including a W3C gorup, to do the same. None of the disparate efforts coalesced into a unified front, so the simple answer is that projects advocated for whatever spec their developers backed. The community is fractured.

Does it matter? If your email client doesn't understand enough of the markdown variant being used, then you should still be able to read the unrendered text. That's one of the great things about markdown.

Can't agree with more. It's a pity these days, for nearly all the WIKIs, CMSes, blog platforms, still markdown is not the native format supported out of the box, most of them needs plugins etc, or you need run a static-site-generator to convert markdown to HTMLs.

I've long thought that YAML instead of JSON and Markdown instead of HTML would be ideal for the average person to get into internet content production and sharing. Combining both specs is YAML Front Matter, where metadata can live with the document.

Sure, the YAML and Markdown specs could be more strict but right now browsers are very tolerant of malformed HTML.

Unlike HTML it would help separate data/content from presentation, which I think is at the root of ads and poor quality content we are forced to sift through now.

I don't have any strong opinion about YAML (or YAML Front Matter), having never used it much, but at a glance it seems reasonable to focus on writing content in.

On a sidenote:

    Sure, the YAML and Markdown specs could be more strict but right now browsers are very tolerant of malformed HTML.

This wouldn't be possible without an extremely well-defined HTML spec :) For example, if I write the following in a hypothetical browser-parsed Markdown document:

     _Hello!_
     *Hello!*
     **Hello!**

Which one should show up as bold? What about italic? Which one should just be surrounded by {1,2} asterisks?

Conversely, if I have:

     <ul>
         <li>Hello</li>
         <li>World!
     </ul>

Many browsers can determine (non-trivially, and not always, granted) that there's an unclosed `<li>` tag inside a closed `<ul>` environment and work with that. It's generally a different class of problems, though.

(non-trivially, and not always, granted)

Note that <li> example is perfectly valid, and will be parsed correctly by any html5 capable parser. Per the html5 spec, the closing tag on an <li> element is optional.[0]

[0] - https://html.spec.whatwg.org/#optional-tags

An li element's end tag may be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element.

Fair enough, TIL. I'd imagine it's much less valid if the missing closing `</li>` is on the first line, though.

No, you can write the entire list without any </li> tags and it's perfectly fine. You also generally don't need to close your <p> tags to start a new paragraph, because paragraphs don't nest inside each other.

This is a perfectly valid html5 document:

  <!doctype html>
  <title></title>
  <ul>
    <li>item1
    <li>item2
  </ul>

First two lines are italic, last one is bold. I'm not sure the point you are making, as all three are straightforward examples of unambiguous Markdown. (There are plenty of ambiguous cases you could have picked...)

IIRC Slack does bold with single asterisks.

But slack doesn't claim to use Markdown.

> Though we understand many people would love to use Markdown in Slack messages, we have no plans to support it. Our message formatting is similar to other popular services like Skype and Google Talk, and is intended for a majority of our users who are unfamiliar with Markdown. However, we'll keep it in mind for the future.

https://get.slack.help/hc/en-us/articles/202288908-Format-yo...

> Which one should show up as bold? What about italic?

Markdown has no notion of italic and bold styling, only semantics for emphasis and strong emphasis.

YAML has the problem that it has a lot of well-defined but incredibly unintuitive behavior.

    // this is a string
    quote: I say, good man, could you spare a vowel?

    // this is a parsing error
    quote: And then I said: "Oh, god, man, you're an aardvark!"

    // this is a string (not including the quotes as part of the string)
    quote: "And then Winston Churchill kicked him square in the knee."

    // this is a string (including the quotes as part of the string)
    quote: |
      "What do you mean, all the monkeys have escaped?"

    // this is a string
    theCharacterToShow: =

    // this is a null value
    theCharacterToShow: ~

    // this is a boolean true
    theCharacterToShow: y

    // this is an integer
    obscureAnimeTitle: 0xDEADBEEF

Are you aware of https://ia.net/writer ? It is a markdown text-editor for MacOS & iOS that many people seem to enjoy.

Reply on news.ycombinator.com