Comment by klodolph | Hacker News Reader

Comment by klodolph | Hacker News Reader

Parent Full thread

It's kind of annoying to see links to other comments in the thread.

https://news.ycombinator.com/item?id=30142334

Markdown syntax IMO is pretty fiddly. I find myself messing with spacing, or with line breaks between list, or things like that. On the whole I find Markdown more annoying than HTML... Markdown is just less typing.

"Markdown" doesn't support TOCs or footnotes any more than HTML does... both TOCs and footnotes are non-standard extensions to Markdown that your particular Markdown engine may support, in ways which are frequently incompatible with other Markdown engines. I found it no trouble to put footnotes in my HTML-based static site generator anyway. I don't expect TOCs would be any different, but I don't use TOCs on my site. Superscripts of any kind are a Markdown extension in the first place, and I'm always so unsure where the superscript ends that I have to try different things and reload the preview until it looks right (this is one of those fiddly bits that drove me away from Markdown).

I guess if you want to target PDF + ePub and others, yes, use something like Markdown. I'm putting video content or interactive content in my blog often enough that it's just not something that would work anyway.

Don't get me wrong... I love using Markdown for stuff like READMEs on GitHub. It's just that for something like my blog, where I put a bit more care into things, Markdown really gets in the way.

In the case of superscripts, the issue is that Markdown doesn't have a concept of nested elements.

In HTML superscript and subscript tags may simply be nested:

  10<sup>10<sup>10</sup></sup>

Markdown implementations ... vary, but typically either a ^<text><whitespace> or ^<text>^ block indicates superscript. That .. doesn't permit nesting:

  10^10^10

or:

  10^10^10^^

... either way is ... ambiguous or undefined. HTML's start/end tag syntax wins.

More generally, where simply writing text, the notion of having bounded blocks and pairs can become confusing, especially where <div>, <section>, or <article> tags are used. I'll frequently find myself unbalanced in those. To the extent that Markdown allows me to Just F*cking Write and not worry about markup ... that's a win. Ironically, for all its reputation for fiddlyness, LaTeX's use of a double carriage return as a paragraph delimiter affords a similar simplicity to much straight prose.

Markdown extension of course vary, but my point remains that using Pandoc (my usual approach), I have as first-class ready-at-hand elements tables of contents and footnotes, both of which I use extensively. I don't have a good formula-entry capability, for which I'd turn instead to LaTeX. I'd also argue that basic table entry in Markdown beats HTML, and is moreover very easy to script given structured input, e.g., with a sed or awk one-liner.

The fact that you seem to be focusing on short content rather than longer pieces may explain some of our differences of views. My typical focus is essay-to-book-length text-heavy documents. If I'm kicking out a short HTML fragment, sure, just code it up directly. Where I'm writing a work which is not specifically intended for the Web, but which could include HTML among other formats, Markdown and LaTeX start making far more sense.

I find complaining about hypertext references to streamline discussion and avoid duplicate content a ... curious gripe in the context of hypertext-authoring tools, but power to you.

When I'm writing HTML, there isn't a ton of nesting. It's mostly <h2> <h3> <p> <figure> at top-level. No parent tags. This is standard HTML, the <html> and <body> are implicit. Sections are implicitly delimited by header tags. Open and close tags are generally no more than a few lines apart. I'm strongly in favor of "semantic" tags in general (and so, for example, I do not use <cite> <em> or <i> interchangeably, even though they are all styled the same) but AFAIK the <section> tag does not really serve a useful purpose, semantically, because sections are already delimited by header tags (and screen readers and the like understand this).

Anything like an <article> or <main> or whatever is going to get handled by the template. I only write the contents of each article, and let tooling handle the boilerplate. Just like how you don't write navigation bars or TOCs in markdown, you let the tooling do that for you.

Re: tables, to each their own... I find tables in Markdown to be a bit fragile and easy to screw up when I'm changing them. I don't like having the columns shoved into one line of text. And any time I'm sticking tables in a document I'm likely to want to adjust the styling a little. Tables are easily the thing I hate the most about markdown.

> Markdown extension of course vary, but my point remains that using Pandoc (my usual approach...

Using some particular markdown tooling you get TOC and footnotes... and using some particular HTML tooling I can get the same thing.

For particular pages I often add small snippets of CSS or JavaScript, which I can just stick in <style> tags at the top, or <script> tags at the bottom, because it's just standard HTML.

I hope you are aware that nearly every markdown renderer respects full HTML right? As soon as you open a HTML tag, you can just treat its insides as HTML. That way you can just write prose when you are in content mode. If you want to switch to dev/designer mode you simply have to open a HTML tag.

When you can simply think of markdown as a syntax tooling on HTML that is widely human readable (by non-web developers!) without stopping you from having the full power of HTML whenever and however you like it, how is that not a win?

> I hope you are aware that nearly every markdown renderer respects full HTML right?

Yeah, I'm aware.

> That way you can just write prose when you are in content mode. If you want to switch to dev/designer mode you simply have to open a HTML tag.

When I want to just write prose, I can use a WYSIWYG word processor. When I want to make a post on my web page, I can write it in HTML. I rarely benefit from having a third option... markdown, the "mediocre at all things" format, which is not good enough to replace a word processor from the 1990s and not good enough to use in place of HTML when I'm making my web page.

I do actually use markdown... for small snippets of notes. I have all my Emacs setup to edit markdown quite nicely. If the notes start getting too large and detailed, I copy and paste the notes to a word processor, so I don't have to deal with markdown's awful syntax. If the notes evolve into a blog post, I'll rewrite them in HTML--I always rewrite notes anyway, before posting. It's much more common that I start blog posts in a word processor, rather than markdown, though.

> When you can simply think of markdown as a syntax tooling on HTML that is widely human readable (by non-web developers!) without stopping you from having the full power of HTML whenever and however you like it, how is that not a win?

This argument is taking for granted the idea that people like markdown syntax, when I thought that I had been pretty clear that I don't like markdown syntax. I think it's just kinda mediocre at lots of different things, and in the end, is worse than just using plain HTML... except for a few niches, like READMEs on GitHub and comments on Reddit.

To be clear, markdown is not a win for using in my website because it makes my tooling more complicated, and it delivers no benefits.

I can understand why some people like it... surely you can try to understand that some people don't, and we don't just dislike markdown for no reason.

> As soon as you open a HTML tag, you can just treat its insides as HTML.

That is not entirely true. There are some edge cases to consider and while considering edge cases, we first need to decide which Markdown flavour we want to use. Some of us also need to consider if we are willing to commit to that Markdown flavour for the next 10, 20, 30 years or so because we do not want to "fix" our content again when some content rendering breaks due to edge cases when we switch from one Markdown renderer to another. The multiple flavours of Markdown handle several edge cases in different ways.

Let us pick CommonMark as the Markdown flavour for this comment. Here is an interesting edge case that is relevant to your comment. Consider the following Markdown input:

  <div>
  *foo*
  </div>

The above Markdown input is rendered as the following HTML output:

  <div>
  *foo*
  </div>

Now consider the following Markdown input:

  <div>

  *foo*

  </div>

This is rendered as the following HTML output:

  <div>
  <p><em>foo</em></p>
  </div>

One can use https://spec.commonmark.org/dingus/ to test these examples.

So as soon as we open an HTML tag, we can't just treat everything inside it as plain HTML. The content within the HTML tags may get interpreted as Markdown as shown in the second example above. Now granted, all of this is clearly specified in the CommonMark specification and these edge cases are handled in this manner for good reasons (such as providing a way to use Markdown syntax within HTML tags, in the above example). But one has to understand the specification very well and keep these edge cases in mind while mixing HTML and Markdown.

For many people, these edge cases are not a problem because they write simple Markdown that would probably get rendered the way they expect, without any surprises. I can understand why many people prefer to use Markdown to write their website content. But there are also some of us, who find this extra complexity to be not worth it, especially because editing plain HTML files is nearly as easy, if not more, with a good editor (Emacs, in my case).

Reply on news.ycombinator.com