We should have Markdown-rendered websites

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.

Or browser just renders markdown directly.

What is needing then, is adding the "type" attribute in command, that browsers with their own implementation can optionally use it instead in order to render with the user's settings if desired.

However, that still forces you to serve HTML, so it is not good. My idea is adding a "Interpreter" response header, which indicates which files can be used to render files (documents, audio, video, pictures, etc) that the client implementation does not understand already. The end user can also specify their own overrides, if desired.

The argument is that if you disqualify everything for not having $FEATURE, where $FEATURE varies from person to person, you have also essentially disqualified markdown entirely. As the saying goes, everyone uses only 10% of Microsoft Word, but everyone uses a different 10% of Microsoft Word. Much the same thing applies to this case for much the same reasons. If your standard is going to be "I want everything in any variant of Markdown ever and also any plugin ever", you will end up with something that is just as complicated as HTML, only different this time. (Possibly even more complicated than HTML.) CommonMark is a decent solution to "I want to use Markdown", if you're willing to take the simplification.

Note in this case I don't think there's anything wrong with refusing the simplification. It's just that if that is your set of your requirements, you've disqualified Markdown entirely. Personally, I think that is the state of the situation; Markdown can't do this. Markdown and all of its family members and close friends intrinsically work by reducing the problem. If you refuse to reduce the problem, you've refused to use Markdown. That is not a moral judgment; that's an engineering judgment. From the position the major browsers operate in, they will never attain anywhere near enough agreement on this to ever implement it without it simply becoming another monster of its own as everybody piles in with all their favorite extensions.

I have some websites that run with Hugo, which is in principle based on Markdown, but if necessary you can have raw HTML pages or other things too. This is actually the ideal; use Markdown when it makes sense, use other things when it doesn't, and thus, neither of those two things has to carry the burdens of the other side. This is the real and best solution, honestly, and it also has the advantage that it's here now. Use whatever flavor you want, where ever you want, whenever you want, today. I'm doing this and I don't see any advantage to trying to convince the browser to do this. I have a deploy step regardless of what I do, so it's no skin off my nose whether that step deploys my pages raw or there's a render step in addition to the deploy.

While I believe you, and that the currently state is too messy, nevertheless it is possible for some implementations to be more limited or to have options for the user to disable some features if desired.

It is true, there are other protocols and other file formats they are good for different purposes, and you should not try to use one for everything. (In my opinion, this is true of Unicode as well; it is messy and doesn't work well to use Unicode for everything, either, nor HTML or HTTPS for everything, or cell phones for everything, or the government for everything, etc.)

It would also be possible to serve text/gemini files with HTTP too, and I also have modified my browser to be able to display them (also local files too), this is not common.