7 ms·

This doesn't really make sense, for a couple reasons... There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all

• ajkjk 4y ago
  > There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. Yes please. Perfect: to want something that can be done; to need something that can happen.
• ElevenLathe 4y ago
  I get this, but OTOH it is IMO best to distribute digital artifacts in the format that is most useful for editing or creating derivative works. This is the free software philosophy but also a societal good. Many of us learned HTML and web technologies by reading the source code of websites, and we've closed that door behind us with all of the build steps that turn our actual code into a computer-readable-only mess which we send out for consumption by normal users' browsers. It would be nice if "view source" showed you something like what the author actually wrote in their text editor.
  • madeofpalk 4y ago
    you can distribute websites as markdown! Return markdown with a plain text content type and it'll show as markdown, which was designed to look good as-is and not require rendering to HTML
    • cxr 4y ago
      Markdown is supposed to (be able to) look good as-is. Most people's Markdown doesn't look good as-is, though. They target the GitHub renderer and come from the GitHub-listing-as-a-product-landing-page school of thought, so even project READMEs are generally a mess.
      • madeofpalk 4y ago
        Presumably if you want to "distribute digital artifacts in the format that is most useful for editing or creating derivative works", like parent said, you would make it look good.
        • Dylan16807 4y ago
          That means you distribute the best you have. It doesn't obligate you to use better methods.
          • ElevenLathe 4y ago
            Exactly this. I was paraphrasing the definition of source code from the GPL: "The source code for a work means the preferred form of the work for making modifications to it."
        • cxr 4y ago
          This isn't an unknowable hypothetical. No need to presume anything. Markdown found in the wild is a mess. The GitHub Flavored Markdown renderer even encourages it.
    • jmull 4y ago
      This is a really good point. (I should have/wish I had brought it up in my original post!
  • krono 4y ago
    Sourcemaps for HTML essentially.
  • gambler 4y ago
    >Many of us learned HTML and web technologies by reading the source code of websites HTML is an extensible language. Markdown is not.
  • saurik 4y ago
    This is actually horrible for society as it implies that the Web Browser will have to implement a billion different parsers for all of the separate file formats it supports, which not only causes it to have a ridiculously large attack surface but pretty much implies there will only be a couple serious separate implementations (if even that soon...) as it is just too difficult for even a large company now to build a browser. Meanwhile, it doesn't even ensure the property of being able to view source, as people can and do obfuscate things they don't want you to see, and if people want you to see the source code there is nothing preventing them from making that entirely pipeline visible, including, but certainly not limited to, shipping a trivial markdown parser to the browser instead of doing the conversion on a server. In a perfect world, the browser should have simply provided something like canvas hooked up to something like WebAssembly, and we should have provided for everyone a trivial markup file format rendered that people could include by default and a handful of graphic file format implementations that could be easily mix-and-matched to pull just the ones people wanted into their site.
• znpy 4y ago
  I came to write something similar to this, basically. If anything we should push for websites to divide content from presentation: if html tags were used properly there would be no need for markdown. And on that matter, pushing for proper use of html tags in documents is a more achievable goal than asking everybody to just drop html and write markdown.
• 6502nerdface 4y ago
  Interestingly, your comment is very similar to the Gemini FAQ "2.9 Why didn't you just use Markdown instead of defining text/gemini?" [1] [1] https://gemini.circumlunar.space/docs/faq.gmi https://gemini.circumlunar.space/docs/faq.gmi
  • merb 4y ago
    https://xkcd.com/927/ https://xkcd.com/927/
    • timdaub 4y ago
      https://timdaub.github.io/2022/08/28/six-unpopular-opinions-about-software-standard-development/ https://timdaub.github.io/2022/08/28/six-unpopular-opinions-...
      • necovek 4y ago
        This fails to differentiate a "standard" from simply a "specification" (of a format, protocol, language...). I.e. we don't say "PostScript standard", but rather a "PostScript specification". All of the claims they make apply to any specification, and yes, divergence is necessary to make progress. A standard is a commonly agreed to specification, frequently ratified in one or another international organization (ISO, IETF, ECMA, W3C...). The main value of a standard is in ensuring interoperability where that matters more than all the other concerns raised. Eg. we'd never have much of the internet if people didn't simply settle on the IP (v4) protocol.
        • deleted 4y ago
          [deleted]
        • timdaub 4y ago
          nice, excuse my ignorance I had actually never seen it differentiated in that way but it makes a lot of sense.
    • harryvederci 4y ago
• jrm4 4y ago
  I can't meaningfully distinguish any of these criticisms from some you could have made about HTML earlier. None of these are deal-killers.
  • MajimasEyepatch 4y ago
    The difference is 30 years of websites and tools being built on HTML. There's an opportunity cost to consider: is formatting simple websites in Markdown and rendering them natively that much more valuable than simply writing them in HTML or using a Markdown-to-HTML tool that it's worth the cost of creating standards, implementing them in browsers, etc. as opposed to putting those efforts elsewhere? If you were starting from scratch, maybe. But it seems like we've already reached a point where existing solutions for Markdown-to-HTML get you almost all of the value and none of the cost.
    • charlieyu1 4y ago
      Adobe was killed rather fast, and I don’t see every part of the HTML+CSS+JS trio is irreplaceable
  • jmull 4y ago
    The difference is that HTML already exists and browsers support it. For browsers to also support markdown, there should be some use case that isn’t already well-supported.
• timdaub 4y ago
  Alphabet is a 1T USD market cap, I‘m confident they could finance implementing 3-5 flavors.
  • jmull 4y ago
    I don't think money is the problem. It's the extra complexity to move markdown rendering from the control/responsibility of the server side, where it fits naturally, to the user-agent side, where it doesn't -- and for something that site publisher can already do (and evidently, rarely want to do).
    • shakna 4y ago
      I don't know why you say it doesn't fit naturally for the client to render a markup format. (With an RFC [0], too) Chances are your client already handles a bunch other than HTML like SVG. Or even contextual ones like WebVTT. [0] https://www.rfc-editor.org/rfc/rfc7763.html https://www.rfc-editor.org/rfc/rfc7763.html
      • chrismorgan 4y ago
        > With an RFC, too RFC 7763 does not define Markdown in any way. It acknowledges both the popularity and messiness of the Markdown family of syntaxes, registers a so-broad-as-to-be-nearly-useless media type for the family, and establishes a registry of variants (https://www.iana.org/assignments/markdown-variants/markdown-variants.xhtml https://www.iana.org/assignments/markdown-variants/markdown-...). Critically here, it does not recognise Markdown as a usable markup format in its own right. Only as a family of often ill-defined syntaxes that may be tolerably readable in raw form, and with the correct, unspecified tools may be converted to a formal markup language like HTML. “Markdown” is utterly unsuitable as a publishing format. It’s designed as a writing format.
• coldtea 4y ago
  >There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. Well, if it were to be adopted by vendors, the many flavors would be a non-problem. They can just agree on a flavor and be down with it. There's CommonMark anyway, they can just use that.
  • seized 4y ago
    Except that CommonMark has its own very annoying things. Like loose lists. Multiple lists of bullet points ends up an ugly mess with CommonMark.
    • v3ss0n 4y ago
      Can you give me an example?
      • seized 4y ago
        This is in ObsidianMD, which uses CommonMark. If you have two lists separated by only new lines: https://imgur.com/IFejJvX https://imgur.com/IFejJvX They render as loose lists (note the ugly spacing that appears) regardless of the number of new lines between them: https://imgur.com/VEiAZKV https://imgur.com/VEiAZKV The workaround is adding a tab (or other character, like a braille space) between the lists, which really makes them one list: https://imgur.com/Z5WLy6w https://imgur.com/Z5WLy6w Which makes it render in a less worse way: https://imgur.com/F5lc0ek https://imgur.com/F5lc0ek This is expected behavior per CommonMark.
    • Beltalowda 4y ago
      "I don't like this standard" is not the same as "there is no standard".
      • seized 4y ago
        I didn't say there wasn't a standard. Just because there is a standard doesn't mean it works well. Hence the whole "more than one standard" situation...
• nine_k 4y ago
  Markdown-based web is actually easy to try. There is a number of browser extensions that render Markdown nicely. Install one, and get your friends do the same. Make your web server serve markdown files with a Content-Type: text/markdown or even text/plain header. Put some Markdown files there. Enjoy. It should just work.
  • Gibbon1 4y ago
    I'd be curious about a browser that just does markdown
• Dylan16807 4y ago
  > There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. HTML has had the exact same problems. You can say "CommonMark spec" and it's solved, isn't it?
  • funnymony 4y ago
    Part of the reason for standards committees, is that just saying “this flavour” is not enough to convince everybody. Standard is not only specification, but also tacit agreement by many parties to use same standard. People that have skin in the game usually want a say on what flavour should it be.
• minhmeoke 4y ago
  For people considering adding Markdown support to web browsers or other publishing tools, please consider adopting Djot instead: https://github.com/jgm/djot https://github.com/jgm/djot It's very similar to the Markdown syntax we all know and love/hate, but fixes many inconsistencies in the spec, and also makes it possible to parse a document in linear time, with no backtracking. It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content. Some examples, showing how Djot would be rendered into HTML: https://htmlpreview.github.io/?https://github.com/jgm/djot/blob/master/doc/syntax.html https://htmlpreview.github.io/?https://github.com/jgm/djot/b...
  • Arainach 4y ago
    The primary goal and appeal of Markdown is that it is easy to write. Optimizing for parsing is creating a fundamentally different product. Standardization of the spec is good. Requiring quirky behavior and blank lines that hurt reading is bad.
    • vintagedave 4y ago
      Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before. > Requiring quirky behavior and blank lines that hurt reading Really? The linked spec says, referring to a blank link in indented lists: > reStructuredText makes the same design decision. And as a design goal: > your document [must be] readable just as it is, without conversion to HTML and without special editor modes that soft-wrap long lines. Remember that source readability was one of the prime goals of Markdown and Commonmark… Or this, which made me celebrate: > anything that is indented beyond the start of the list marker belongs in the list item. In Markdown it’s really hard (aka impossible) to get sections to respect the indentation level they belong to. What a simple rule here: inside a list, items belong to their list item. Beautiful! Other great quotes: > we don't need two different styles of headings or code blocks. > avoid using doubled characters for strong emphasis. Instead… use _ for emphasis and * for strong emphasis > code span parsing does not backtrack. So if you open a code span and don't close it, it extends to the end of the paragraph Sanity. Sanity introduced to an ambiguous spec. It’s wonderful. This bit made me a little unsure: > although we want to provide the flexibility to include raw content in any output format, there is no reason to privilege HTML. For similar reasons we do not interpret HTML entities, as commonmark does While Markdown was meant to transform to HTML, I wish it was a spec renderable without a HTML or web browser layer. So I like this. Equally though one use case I personally have is Markdown to static HTML and it’s useful having HTML tags present and handled. So my understanding of this part of the spec is confused (what does “interpret” mean?) but if it means no support for inline HTML that is indeed a pity.
• divan 4y ago
  > markdown is designed to transform to HTML Is it though?
  • nerdponx 4y ago
    More or less, yes.
    • divan 4y ago
      less
  • hoppyhoppy2 4y ago
    >Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML). From 2004 https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/
    • divan 4y ago
      > Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML. I believe nowadays most people refer to (1) instead of Perl tool, when talking about Markdown. Personally I use Markdown *a lot* for Flutter apps, where text is rendered natively. Also use it for legal documents, which are converted to PDF via pandoc. Another project I have is a console app that also shows formatted help text written in Markdown. In all these cases there is no HTML whatsoever and no 'text-to-HTML conversion tool'. Yet it's all Markdown, so no need to reduce its applications to HTML, let alone claiming that it's designed "to transform to HTML".