61–70 of 120 posts
Markdown has always supported direct raw HTML in it. I don't see any gulf or sudden jump in cost. Don't be a Markdown purist. Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. He doesn't even do multi-paragraph ordered lists in Markdown, and chooses to write instead. And he also uses for clickable ima…
> Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. John Gruber is the worst possible authority to reference here. He’s a bad steward of the standard and Markdown is popular despite him, not because of him. His own implementation has bugs that will never be fixed, doesn’t support features we all take…
More context:
https://github.blog/engineering/user-experience/a-formal-spe...
Markdown has always supported direct raw HTML in it. I don't see any gulf or sudden jump in cost. Don't be a Markdown purist. Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. He doesn't even do multi-paragraph ordered lists in Markdown, and chooses to write instead. And he also uses for clickable ima…
I can say that on my website, which is certainly 'richer' than most Markdown-oriented websites, we scarcely ever think about Markdown as a limitation to implementing a feature. Nor was it a serious hindrance at any point. There have been issues, sure, but pretty much never do we tear our hair out going, 'how can we possibly implement transclusion properly, when the source is written in Markdown rather than Asciidoc??? Woe is us!' That's just not a thing.
When we have issues, it's almost always related to something about the Pandoc internal API design choices (essentially unrelated to any syntactic sugar and would be equally true if we were starting from a different input type) or the sheer difficulty of implementing anything well & reliably cross-platform/device/mode. The Markdown part of our discussions usually boils down to a debate over the naming of a class. Because setting the class on whatever element is a non-problem, already solved, and we move on to the real challenges to adding a rich feature.
To whatever extent his imaginary gap exists in reality, I would bet it has far more to do with dynamics around websites which happen to use Markdown, like trying to cater to the lowest-common denominator and banning HTML fragments, and stuff like that.
Markdown has always supported direct raw HTML in it. I don't see any gulf or sudden jump in cost. Don't be a Markdown purist. Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. He doesn't even do multi-paragraph ordered lists in Markdown, and chooses to write instead. And he also uses for clickable ima…
On the note of embedding HTML in Markdown, I think it'd be cool if it were just as easy to embed Markdown in HTML. Something akin to a tag. Markdown makes it easy to write formatted content at the cost of initial compiler setup, HTML is 0-cost setup but takes some effort to write formatted content. With a tag one could start with vanilla HTML at zero cost, use all its features straight away, but not have to type HTML…
You can verify the content with : curl https://www.tducret.com/pure-markdown/
> The impact of Markdown becomes clear if we plot a random sample of content websites. (Disclaimer: the data is made-up, based on my perception of the state of the web)
Perhaps the author's thesis is wrong.
> A great example of a rich content website is the Tailwind CSS landing page. This is a pretty bad example, right? It is the landing page for some web framework or whatever, that shows you it can make over-complicated websites by being itself an over-complicated website. It is being good at its job in some sense no matter what it does, because the thing it is showing is… the thing that it does. But, this doesn’t show…
The authors solution is more frame works to bridge the gap, but the only evidence for something beyond that gap is itself a framework.
Doubly troubling is that theyre pushing their own frame work, that presumably they think solves some real world problem, but can point to a concrete example of what theyre solving.
Finally. If you want to foist a complicated website on a user, you can't complain about complexity in the creation of the site. Quite why a dev feels the need to push a framework, to make a fancy site, just for me to install an ad blocker to remove the fancy (I assume thats what were really talking about here) to get back to markdown levels. I don't know.
> The impact of Markdown becomes clear if we plot a random sample of content websites. (Disclaimer: the data is made-up, based on my perception of the state of the web) It makes sense that your perception of the web has driven you to create a new tool and market it with a think piece. But to expand that to suggest you have effectively realized and filled a new vector space in the web is excessive >That sparse area ju…
I find that most of the use cases in that 'wasteland' would be made better by reducing the fluff and focusing on content. In my younger days, I chafed at the restrictions of Markdown and similar tools. However I now appreciate that the results are almost always easier to read.
Earlier quoted context omitted.
On the note of embedding HTML in Markdown, I think it'd be cool if it were just as easy to embed Markdown in HTML. Something akin to a tag. Markdown makes it easy to write formatted content at the cost of initial compiler setup, HTML is 0-cost setup but takes some effort to write formatted content. With a tag one could start with vanilla HTML at zero cost, use all its features straight away, but not have to type HTML…
That sounds like a good idea, until you remember that there is no officially agreed upon markdown spec. For content authors it'd be both fantastic if browsers could just go "you guys go fight it out, we're just gonna go with GitHub flavored markdown" but at the same time for browser makers that's taking a position on something that they have no stake in. So writing or using someone else's custom element is pretty muc…
Although of course in practice, commonmark renderers are not plentiful or up to date. In my experience, most library authors end up just implementing the bits of Markdown they care about and the behavior they prefer for the ambiguous parts.