Hacker Newsnew | past | comments | ask | show | jobs | submit | xigoi's commentslogin

The government already knows whether you have a car. What more information would they need?

If the tool that allows you to have a “noticeably better life” is heavily subsidized by venture capital, you have turned yourself into a ticking bomb.

I would certainly not consider package management to be a good part of JavaScript (or Rust, for that matter).

There is no such thing as a common subset of Markdown. Even basic things are rendered inconsistently by different implementations. If browsers decided to add Markdown support, this would lead to another “works only in Internet Explorer” situation.

> There is no such thing as a common subset of Markdown.

That was true before the widespread use of generative AI. LLM-generated markdown could _become_ the most common subset of Markdown, since machines can generate Markdown faster than humans.


“LLM generated Markdown” is not a coherent description of a language. LLMs can generate anything they have seen in their training data, which includes many incompatible dialects of Markdown.

Major LLMs (e.g. ChatGPT) have a copy button for their output, yielding markdown that is already being consistently rendered by other apps, reflecting what was consistently rendered as HTML. Presumably LLM vendors have built a deterministic way of generating spec-compliant HTML and their well-defined dialect of Markdown, otherwise their chat UI output would not render consistently.

I have certainly seen LLMs generate broken Markdown, so it’s presumably a “hope it works” thing.

I like it, but it doesn’t seem to have a specification, making it hard to create a new implementation.


That’s a reference, not a specification. I would expect something like a formal grammar or a description of a parsing algorithm.

Like the original Markdown. :)

However, there is no way to switch back to Markdown inside HTML, so if, say, you want to have an <article> tag around your article, you need to write it entirely in HTML.

> That’s just an accident of whatever editor you might be using, not of others.

And that’s the main issue with Markdown.


I’m pretty sure many Markdown implementations would turn this into a code block. Unfortunately Babelmark seems to currently be broken so I can’t test it.

The original spec says it should work, and it does with <https://daringfireball.net/projects/markdown/dingus>, as with <https://spec.commonmark.org/dingus/>.

> What it can't do (as far as I understand): complex layouts, precise typography, embedded binary content, anything that needs pixel-perfect rendering. Am I missing anything? What are the other limitations I should know about?

Off the top of my head: Math typesetting, semantic markup, small caps, document sectioning. (All of these things are very important for me.)


The mistake people do is thinking markdown is something else than a text file formatting convention that is easily converted to other formats to make it prettier.

If what you want to do can't be done by a text file hosted on a gopher server, it just means markdown is not for your usecase.

Markdown is not meant to replace Latex or Microsoft Publisher.


That would require Markdown to be standardized. (There is the CommonMark standard, but it’s extremely complex and still ambiguous.)

You could still support a subset of the most common features like bold, italic, strike, bullets, links, etc.

Isn’t the beauty of MD supposed to be that if you can’t render it it should still look fine as plaintext?


Even these basics are not consistent. See my Markdown Monster:

https://git.sr.ht/~xigoi/markdown-monster/blob/master/monste...


The problem for web browsers is that markdown is technically a superset of HTML.

Why is this a problem? To me it sounds like a it would be an advantage because you have everything you need to render it already built into the software.

Rendering is trivial. The issue is standards, and the DOM. No-one can write a Markdown implementation for the core of any major web browser in a form that is simultaneously acceptable to both their technical and political governance.

Best you’ll get is a plugin. Strictly arm’s reach. Translation only.


Why is it a problem for web browsers?

I don't think so. I think it would be sufficient to document the exact markdown it supports and let the chips fall where they may. Yes, it would push markdown in a certain direction, but that's OK as long as it stays faithful to some variant most people already know. For instance whatever variant Github or some other major, main stream tool uses. And then just ignore the critics.

It'll certainly make some people angry, but if we try to please everyone we can't get anything done. And I suspect that it is the fear of not being able to please everyone that is the reason browsers do not have markdown support. It takes a bit of courage to say "this is the variant we'll implement".

HTML was originally said to be an application of SGML. It wasn't. It was vaguely inspired by its syntax and that is the only reason HTML saw wide adoption. Had they tried to actually implement anything close to ISO 8879:1986 we would NOT have adopted HTML for the web. Mostly because it would have been too costly to implement. (Anyone doubting that: have a look at the ISO standard. You can get it in what is essentially annotated form in Charles Goldfarb's "The HTML Handbook").

Of course, Markdown is nowhere near as complex. So this is where perfect is the enemy of good and we end up getting nothing.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: