Markdown (often as Commonmark) is very often used on the Web for user input of both short and long texts, e.g. articles and comments. However, in order to assist their users, site authors need to implement any further support for this common language themselves or by using third-party libraries. HTML elements <input> and <textarea> (or ones with the attribute contenteditable) do not support a native text/markdown mode, which would instruct the browser to highlight or style the syntax, provide WYSIWYG-like editor buttons or switch to a touchscreen keyboard layout with frequently used punctuation marks shown more prominently.
Also, without third-party extensions, browsers do not handle text/markdown (RFC 7763) files any different than text/plain, i.e. neither display them with enhanced formatting nor let users convert them to HTML.
There is no (browser-supported) way to apply CSS (or any other styling language) to Markdown content directly, although some selectors, e.g. pseudo-classes :link (very old) and :heading (very new), would apply in a straight-forward way, and per RFC 8288 there is a standardized way to associate a stylesheet with arbitrary resources within an HTTP response header: Link: </md.css>; rel="stylesheet". Additional semantic selectors or a generic one based on (implied) ARIA roles could help to solve this.
How could these steps be promoted and advanced?
Which other measures could be undertaken to make Markdown a first-class citizen on the Web?
PS: I consider support for text/markdown MIME content in emails a related but different issue.
No component of the Web platform has ever been perfect, I believe. I don’t see why adding support for dealing with Markdown would require its spec to be perfect.
I think this is ill-advised and could damage the Markdown ecosystem, without bringing any practical benefits.
CommonMark is already defined in terms of HTML and plays very nicely with other web technologies. It seems misguided to force web browsers to implement a particular flavor of Markdown, just so that some web developers can save a single dependency on a particular UI component. The other use case mentioned – automatically rendering documents served as text/markdown – is a solution in search of a problem. You can get a browser extension to do that for you if you really want it. Standardizing such behavior would add complexity to the web platform with no functional benefit.
The ecosystem is quite healthy in its current, non-standardized form, where the particular choice of flavor and processor is left up to the author, or, in the case of hosted content, the website developer. There are at least three major uses of Markdown on the web:
To render READMEs and technical documentation on source code hosting sites like GitHub and GitLab.
To support marking up forum posts and comments.
As a component of a site generator.
These use cases tend to prefer different versions of Markdown, e.g. GLFM for the first one, CommonMark for the second, and Kramdown for the third. These flavors (and their implementations) are all incompatible in various ways. For instance, while typing this reply, I noticed that the version of Markdown on this site extends CommonMark with [quote]...[/quote] delimiters.
If a single Markdown flavor (or even a small handful) were made into a standard and incorporated into web browsers, it would struggle to accommodate all of these use cases. For users, a gap would arise between “the version of Markdown supported by my browser” and “the version of Markdown I want to use,” which could harm adoption of Markdown.
Since CommonMark’s semantics are defined in terms of HTML, there is a clear way to style CommonMark documents using CSS. This is one of the biggest benefits of using HTML in the spec. If someone adds a way to style abstract Markdown documents as well, it must behave identically. Otherwise you would need one stylesheet for the Markdown document, and a different stylesheet for the HTML output produced by the Markdown processor.
Most components of the web are designed with extension points, so that they can be improved without breaking existing pages. HTML ignores unknown tags and CSS ignores invalid rules. JS throws if you call an unknown method.
If you write something that Markdown doesn’t recognize as syntax, it just gets rendered as text. If a browser adds a new feature to an existing Markdown parser, documentation that pre-dates the feature may contain valid, but meaningless, syntax for the feature. So applying the feature to docs that didn’t intend to use it produces corrupt gibberish. You can reduce how often this happens by requiring more characters to trigger the feature, but the whole point of using “native Markdown” instead of embedded HTML is that it’s more terse.
Are we also going to make Atlassian Document Format a first-class citizen of the Web? Frankly, I would prefer that, ha. It’s a much better serialization format. - See https://developer.atlassian.com/cloud/jira/platform/apis/document/playground/ - Note, I do not like Atlassian products very much, but we currently have a bunch of agent skills that convert markdown/html to ADF, and it’s made me appreciate how much better engineered ADF is for working with the Web and Agent protocols than Markdown. I am getting tired of using VSCode Markdown editor/preview - it’s extremely limited, and even has some annoying bugs.
Every part of the web platform has a way to grow. HTML ignores tags it doesn’t know.
CSS drops rules it can’t parse. In both cases the old document still means what it
meant, and the new feature just doesn’t apply to it. Markdown has no such room. It
doesn’t ignore what it doesn’t know, it re-reads it. Plain text today can be syntax
tomorrow. Or least it would also need some versioning or alike.
GitHub’s alerts are a small example: > [!NOTE] used to render as a blockquote with
some literal text in it, and now it’s a callout box. Fine for a site that can decide
that for itself. Not fine for a parser in the browser, which either freezes forever or
changes what old documents mean, quietly and with no error.
@pugmire is right about CSS - Markdown being defined in terms of HTML is what makes styling easy, and it’s also why there’s not much to standardize. Two implementations give you two different trees. They only agree at the end.
The ADF mention is interesting for what’s missing. A schema’d tree is good for tools
and agents, but nobody writes it by hand. Markdown is the opposite: easy to write,
nothing agreed underneath. And the flavors You’d want both - a text syntax where the spec is the
document model, and syntax kept unused on purpose so new features don’t rewrite old
files.
I work on a Markdown-ish new language incl clear spec/AST that should also solve some of the issues above called Carve.
But still doesnt belong in a browser. Having this work out of the box easily due to WYSIWYG, TreeSitter, TipTap etc. seems still easy enough without the lock-in of the syntax for years to come.