5 ms·

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 hav

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!

ausjke 10y ago
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.
doublerebel 10y ago
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.
- verandaguy 10y ago
  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.
  - dsp1234 10y ago
    (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 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.
    - verandaguy 10y ago
      Fair enough, TIL. I'd imagine it's much less valid if the missing closing `</li>` is on the first line, though.
      - mbrock 10y ago
        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.
      - dsp1234 10y ago
        This is a perfectly valid html5 document: <!doctype html> <title></title> <ul> <li>item1 <li>item2 </ul>
  - deleted 10y ago
    [deleted]
  - nicky0 10y ago
    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...)
    - nitrogen 10y ago
      IIRC Slack does bold with single asterisks.
- crooked-v 10y ago
  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
bhaak 10y ago
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.
- verandaguy 10y ago
  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!
- Ajedi32 10y ago
  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/ http://commonmark.org/
  - legulere 10y ago
    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.
    - Ajedi32 10y ago
      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/ http://spec.commonmark.org/0.27/
      - the_duke 10y ago
        You may want to work on specifying a formal grammar in EBNF or similiar. Great for library / parser implementers and it helps discover ambiguities.
tlow 10y ago
Are you aware of https://ia.net/writer https://ia.net/writer ? It is a markdown text-editor for MacOS & iOS that many people seem to enjoy.

ausjke 10y ago

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.

doublerebel 10y ago

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.

verandaguy 10y ago
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.
- dsp1234 10y ago
  (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 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.
  - verandaguy 10y ago
    Fair enough, TIL. I'd imagine it's much less valid if the missing closing `</li>` is on the first line, though.
    - mbrock 10y ago
      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.
    - dsp1234 10y ago
      This is a perfectly valid html5 document: <!doctype html> <title></title> <ul> <li>item1 <li>item2 </ul>
- deleted 10y ago
  [deleted]
- nicky0 10y ago
  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...)
  - nitrogen 10y ago
    IIRC Slack does bold with single asterisks.
crooked-v 10y ago
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

bhaak 10y ago

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.

verandaguy 10y ago
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!
Ajedi32 10y ago
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/ http://commonmark.org/
- legulere 10y ago
  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.
  - Ajedi32 10y ago
    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/ http://spec.commonmark.org/0.27/
    - the_duke 10y ago
      You may want to work on specifying a formal grammar in EBNF or similiar. Great for library / parser implementers and it helps discover ambiguities.

tlow 10y ago

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