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 <ol><li><p> instead. And he also uses <a><img> for clickable images. You can append ".text" to any of his blog article to get the Markdown source; example https://daringfireball.net/2020/10/the_iphone_12_and_iphone_...
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 <markdown> 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 <markdown> tag one could start with vanilla HTML at zero cost, use all its features straight away, but not have to type HTML for the simple, "content" parts of a site.
EDIT: there seem to be web components for this already:
> 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 for granted as basic Markdown, and he refused to even acknowledge when someone wanted to make a proper standard out of it. If Markdown were left to him, none of us would be using it and would have come up with something inspired by it but probably better and without a myriad of competing implementations with different levels of support.
> Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML.
In situations where, if he used any parser other than his own stagnant code, the whole post could have been written in Markdown. For crying out loud, in the page you linked he has Markdown tables (which his parser does not support) inside HTML comments followed by HTML tables. Daring Fireball is a popular site, but it’s not an example of good design or content structuring. To this day it’s still annoying to read on mobile.
Then you missed the core point of the article, so I'll try and rephrase it:
While you're staying in Markdown-only land (the left part of the article's graph halfway down the article: low-medium richness (horizontal), very low complexity (vertical)), you are not learning HTML.
You miss the "onboarding" process to the richness of HTML, so when you reach the limits of what Markdown can do, and suddenly you need something medium-rich... you have to play catch-up to learn all the HTML that you avoided by sticking to Markdown. That's the gap.
The fact that Markdown supports in-line HTML allows you to bridge the gap, but is irrelevant to the point.
Yeah, I don't buy the theory either. Markdown has always made it easy to just drop in a bit of HTML wherever you need it, and major dialects like Pandoc Markdown support even more. You can set class, ID, and data-attributes on most elements, such as links, or write any div/span placeholder you need natively. (I don't even bother to use the native syntax because writing a '<div class="foo">bar</div>' is so easy.) What 'rich' features is that impeding?
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.
So? I could write my blog post in raw HTML without using any markdown at all. But we don't, because raw HTML is a bad tool for composing rich content.
The kind of things I want to be able to do (that markdown makes hard):
- Make a standard component for embedded images, which supports clicking the image to see it full-screen.
- Make "boxes", showing certain kinds of content. This is useful for diagrams, commentary, code, formulas, and more depending on what you're doing.
- Run code when building the page which can load external data and display it however I want. For example, I wrote a paper using typst recently. I have some data in a JSON file. My typst paper contains code to read in the JSON file and embed some of the values into a table in the output.
- Embed raw SVGs into the output, in an svg tag.
- Have programmatic content - eg, onclick handlers, hover states, etc.
- Make a table of contents (I think GFM supports this, but I don't think its a standard markdown feature)
- Have generated section titles (Eg "3.a Benchmark results")
- Make a webpage which contains content from a lot of markdown files in a folder. Each of those files may need custom ... well, everything.
- Use custom CSS styles. Styles might be local (just this element) or global across the page.
- Use extensions / plugins for things like programmatic diagrams
Raw HTML is a complete non-answer to this stuff. Its the sort of answer that makes me question if you've done any serious writing at all. Like, your comment reads to me as the writing equivalent of arguing that C is the best programming language because - if you need anything thats not in C, you can write it in assembly.
What I really want is some combination of markdown + react. Typst is close - or, it will be close once it supports HTML output. But markdown simply isn't powerful enough for serious writing.
> 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 just beyond the limits of Markdown is of vital importance to the web. These websites are not only a joy to read but also the ones that explore the web's possibilities, embracing the medium and evoking a truly web-native feel.
>Currently, these websites are outliers created by individuals who care deeply about the reader's experience or by companies willing to invest extra effort. We need more of them.
Interesting to me that you have added "focus on this paragraph" coloring to your site. I'm not against that in principle, but you have placed it farther up the page than I prefer to read and scroll. So you care deeply about my experience, have created a whole tool to inhabit an area of web design that you think is undeserved, rationalize it based on feels, and, for me, deliver a poorer experience to show it off.
"The Website Wasteland", as you call it, is a good thing if this is the result of populating it.
well put, and I had thoughts just like this while reading the linked article.
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.
Eh, maybe that's excessive for you and the kind of writing you do. But I think the author is right - there's plenty of valuable writing where being able to customize the page more is valuable.
The most obvious example to me is academic articles - where you need footnotes, figures, algorithm blocks, appendicies, math, numbered sections, and so on. Markdown doesn't support any of that stuff and latex is horrible on the web. It would be great to have something with support for those features, but that also supported HTML output.
But, there's plenty more examples where being able to make richer content than markdown supports is super valuable. For example, Bartosz Ciechanowski's blog is incredible:
Doing anything like this in markdown is hard. You're kind of fighting the tool. The ideal tool would support custom components + custom styling - which aren't supported at all by markdown.
This whole comment thread is weirdly down on the article. I suspect most people have simply never come up against markdown's limitations while doing technical writing. They're quite severe whenever the output of your documentation needs to be a rich website or paper, not just a documentation file in a github repository.
> 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 any evidence that any other websites need to be as interactive and dynamic as the tailwind website (they don’t).
Websites are all over-complicated, markdown is no curse. If this wall is true, it is a blessed line of defense.
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.
Everyone else in the world - and I mean everyone - who is not a software engineer - does not use Markdown.
There is a reason for that. And it's not because they're all stupid and software engineers are all geniuses.
It's because normal people do not want to spend their day wasted in minutia, carving out huge chunks of technical jargon, just to get some words on a page to show up with a certain layout and format.
They want to highlight some text, and click the Bold button, or maybe Ctrl+B, and see the text become bold. They don't want to write code. They want to just make a fucking document, so they can get on with their day.
We have had programs that do this for about 40+ years now. They are called word processors and presentation tools. They work very well, and require absolutely zero code or weird characters.
But software engineers are so insanely out of touch, so cluelessly locked into their web browsers, that they literally cannot imagine a universe in which a person isn't writing code to get some text to show up on a screen, formatted and laid out.
It literally feels like everyone in this industry is insane.
> It's because normal people do not want to spend their day wasted in minutia, carving out huge chunks of technical jargon, just to get some words on a page to show up with a certain layout and format.
> They want to highlight some text, and click the Bold button, or maybe Ctrl+B, and see the text become bold.
They do not. No normal person has ever said how happy they were that they could highlight text and click a button, and certainly not that they typed Ctrl+B. Normal people do not type Ctrl+anything.
Normal people don't type text at all, but if you find the most normie internet forum you can think of - one where people talk about car parts or who the Khardasians are dating or something - you'll find it has some kind of text markup format, and the most prolific users of that forum use the markup format rather than the WYSIWTF editor that craps up their formatting too much. And if you ever find a topic with two competing norie fora, you'll find the people on the one whose text markup format is more markdown-like will be happier than the people on the one whose text markup format is less markdown-like.
Everyone and that even includes many software developers uses unprofessional tools. Wysiwyg and pressing buttons are easier when you start. Text-only sources and mark up (like Markdown...) are more powerful when requirements grow.
Just as an example: We use Google's office suite in our company because there are some users who believe it is more user-friendly than storing text and a proper version control. For version control Google offers named versions. Last week some Google sheet reached its 16th version. Well, would have reached, if Google did not limit the number of named versions to 15. You cannot run a business with serious audit trail requirements using so-called user-friendly "everyone uses" tools. Everyone has horrible standards and inappropriate IT continues to lower them. It's a fact, but not a fact anyone should praise.
Hi. I'm not a software engineer. I write a lot, and I use Markdown for most of it, including in professional context as a team manager. Even for things as simple as call notes (just a bullet list, but that's THE POINT).
Extended (or rather, distended) Markdown flavors always make me queasy, and I don't love the snippet from Code Hike. In my mind, Markdown is fundamentally intended to be lightweight--something for a Reddit post or a blog comment. Heavily extending its syntax instead of choosing a saner syntactic basis strikes me as ill-advised. But one can't deny the advantages for adoption to be had from using Markdown as a starting point, and the project appears to be very popular, so perhaps worse is better.
> Currently, these websites are outliers created by individuals who care deeply about the reader's experience or by companies willing to invest extra effort. We need more of them.
The premise is deeply flawed. Richness is not a sign of care or investment in the reader's experience. Often it's exactly the opposite. Often richness is gaudy and pointless while simplicity makes content clearer and more useful. Maybe this is a great and valuable tool for certain use cases, but the justification here is weak.
Yup, the author's website is an example of this. Their flashy graphic that animated while scrolling did nothing for the content. In fact, their font was so small I could not read the text without zooming in, which completely contradicts the whole premise of the piece -- that a lack of "richness" is preventing ideas from being communicated. If richness prevents your ideas from being transmitted outright, then what's the point? If the author had used Markdown their idea would have been better communicated, but I guess that also would have contradicted it.
Opened this site to find the readable text was squashed into the middle maybe 10% of my screen, as much as markdown can be annoying - websites that refuse to use a reasonable portion of the browser width for readable content annoying me far more.
This doesn't back the hypothesis that there are applications (cough opportunities) held back by markdown's deferral of styling.
Markdown's chief feature is to be usable without tooling when writing, so more content is generated in the first place. So it extends the rich/cost graph to the left.
Because markdown is easily and often parsed, it operates as a data source from the get-go, mostly achieving the separation of concerns needed to scale to the right.
What are the pain or price points that will change with adopting this new technology?
(Is Swift-docc really the comparable? It seems to show what this is hopefully not: a subset dialect of markdown struggling with volatile, unusable hash links, no real extensibility or inter-op, tethered to BigCo's mission.)
This would be a much better article if two things changed: One, skip the scroll gimmick. It's a waste of time and space (and that has been discussed enough)
Two, give us examples that live in that supposed wasteland. Without those, it looks like you're building a technology in the abstract. And, don't get me wrong, it's cool tech. It so tickles my sense of "fun engineering challenge, great way to express structure". But I've long learned that means it's also very likely in the "overengineered" corner.
I share your belief that there's a "there" there. (I'm on my umpteenth iteration of my own personal markdown, so I would ;) I think it'd be helpful to crystallize that into more concrete uses.
This entire argument is weird. My website is relatively rich in content, in different contexts, including (now out of date/deprecated) interactive tutorials. Every single thing on my website is statically generated from Markdown.
Nothing about richness or leanness is implied or enforced by using Markdown for text, it's about everything else around it. On a statically generated page, you do it in Javascript, and render client-side if needed w/ data prepopulated in static objects. The only thing you can't do with a static page that ingests text as RST or Markdown or any other markup language, is something that requires dynamism with a backend database.
This is trying to blame Markdown and statically generated sites for leanness, but minimalism is a stylistic aesthetic choice people made that was a trend for awhile, it's not a requirement of the technology. The technology is just a tool.
> 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)
“I have created a tool, and I’m imagining that it’s very important. Just look at this data I made up!” What a joke.
I think the author forgot to think about the content and got all invested in the display of their site. Should have just used markdown and spent the saved time looking for actual real data.
> This jump in cost disrupts the trade-off between richness and effort. For content with a sweet spot just beyond Markdown’s limits, the additional effort often seems too high for the small gain in richness, leading to a preference for staying with Markdown and sacrificing richness.
Why is asciidoc not more popular? It seems to support more than markdown and seems straightforward.
> Imagine how many ideas are held back because their authors don’t have the right tools to express them.
IMHO article would be much better while not exploring new ideas and use simple text and web-native controls instead of inconvenient accessibility-wise poor UI/UX.
Almost all of the blog posts and articles I write nowadays are in Markdown, and it sure is painful sometimes when you need formatting that you just need a liiiitle bit of tweaking to get right.
My solution is to fork the markdown tool I use to add my own tweaks. Some of the changes I added are:
- Vertical padding: Typically, `---` and `*` get converted to `<hr>` tags. I use `*` for `<hr class="small">` that has different padding top/bottom.
- Code examples with syntax highlighting.
- Block quotes with class names: `> {.warning}`
- Headers and table rows with support for setting a specific anchor ID: `# Header {#myId}`
- `<img>` tags with CSS URL matching to apply certain styles. For example, match `<img>` tags URLs ending with `#screenshot` will have drop shadow.
The first example website given here is described "just text with minimal styling." It's not just text though, it's hypertext? Since when did everyone lose sight of what hypertext is.
I really like the format. The problem with slideshows is you either have to scroll back and forth or click on the next page buttons. This page fixes both of them. Although I can see how the fading out of the text is a bit annoying.
Also is anyone building websites with markdown? I thought it was just a tool to format notes and blog posts. And even then you can insert HTML in it.
[+] [-] kccqzy|1 year ago|reply
[+] [-] aylmao|1 year ago|reply
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 <markdown> tag one could start with vanilla HTML at zero cost, use all its features straight away, but not have to type HTML for the simple, "content" parts of a site.
EDIT: there seem to be web components for this already:
- https://github.com/xan105/web-component-markdown
- https://www.webcomponents.org/element/zero-md
- https://www.webcomponents.org/element/@vanillawc/wc-markdown
[+] [-] latexr|1 year ago|reply
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 for granted as basic Markdown, and he refused to even acknowledge when someone wanted to make a proper standard out of it. If Markdown were left to him, none of us would be using it and would have come up with something inspired by it but probably better and without a myriad of competing implementations with different levels of support.
> Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML.
In situations where, if he used any parser other than his own stagnant code, the whole post could have been written in Markdown. For crying out loud, in the page you linked he has Markdown tables (which his parser does not support) inside HTML comments followed by HTML tables. Daring Fireball is a popular site, but it’s not an example of good design or content structuring. To this day it’s still annoying to read on mobile.
[+] [-] cdchn|1 year ago|reply
[+] [-] AceJohnny2|1 year ago|reply
Then you missed the core point of the article, so I'll try and rephrase it:
While you're staying in Markdown-only land (the left part of the article's graph halfway down the article: low-medium richness (horizontal), very low complexity (vertical)), you are not learning HTML.
You miss the "onboarding" process to the richness of HTML, so when you reach the limits of what Markdown can do, and suddenly you need something medium-rich... you have to play catch-up to learn all the HTML that you avoided by sticking to Markdown. That's the gap.
The fact that Markdown supports in-line HTML allows you to bridge the gap, but is irrelevant to the point.
[+] [-] gwern|1 year ago|reply
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.
[+] [-] josephg|1 year ago|reply
The kind of things I want to be able to do (that markdown makes hard):
- Make a standard component for embedded images, which supports clicking the image to see it full-screen.
- Make "boxes", showing certain kinds of content. This is useful for diagrams, commentary, code, formulas, and more depending on what you're doing.
- Run code when building the page which can load external data and display it however I want. For example, I wrote a paper using typst recently. I have some data in a JSON file. My typst paper contains code to read in the JSON file and embed some of the values into a table in the output.
- Embed raw SVGs into the output, in an svg tag.
- Have programmatic content - eg, onclick handlers, hover states, etc.
- Make a table of contents (I think GFM supports this, but I don't think its a standard markdown feature)
- Have generated section titles (Eg "3.a Benchmark results")
- Make a webpage which contains content from a lot of markdown files in a folder. Each of those files may need custom ... well, everything.
- Use custom CSS styles. Styles might be local (just this element) or global across the page.
- Use extensions / plugins for things like programmatic diagrams
Raw HTML is a complete non-answer to this stuff. Its the sort of answer that makes me question if you've done any serious writing at all. Like, your comment reads to me as the writing equivalent of arguing that C is the best programming language because - if you need anything thats not in C, you can write it in assembly.
What I really want is some combination of markdown + react. Typst is close - or, it will be close once it supports HTML output. But markdown simply isn't powerful enough for serious writing.
[+] [-] apitman|1 year ago|reply
nc apitman.com 2052 <<< /txt/feed
[+] [-] misthop|1 year ago|reply
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 just beyond the limits of Markdown is of vital importance to the web. These websites are not only a joy to read but also the ones that explore the web's possibilities, embracing the medium and evoking a truly web-native feel.
>Currently, these websites are outliers created by individuals who care deeply about the reader's experience or by companies willing to invest extra effort. We need more of them.
Interesting to me that you have added "focus on this paragraph" coloring to your site. I'm not against that in principle, but you have placed it farther up the page than I prefer to read and scroll. So you care deeply about my experience, have created a whole tool to inhabit an area of web design that you think is undeserved, rationalize it based on feels, and, for me, deliver a poorer experience to show it off.
"The Website Wasteland", as you call it, is a good thing if this is the result of populating it.
[+] [-] metalliqaz|1 year ago|reply
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.
[+] [-] josephg|1 year ago|reply
The most obvious example to me is academic articles - where you need footnotes, figures, algorithm blocks, appendicies, math, numbered sections, and so on. Markdown doesn't support any of that stuff and latex is horrible on the web. It would be great to have something with support for those features, but that also supported HTML output.
But, there's plenty more examples where being able to make richer content than markdown supports is super valuable. For example, Bartosz Ciechanowski's blog is incredible:
https://ciechanow.ski/gps/
Doing anything like this in markdown is hard. You're kind of fighting the tool. The ideal tool would support custom components + custom styling - which aren't supported at all by markdown.
This whole comment thread is weirdly down on the article. I suspect most people have simply never come up against markdown's limitations while doing technical writing. They're quite severe whenever the output of your documentation needs to be a rich website or paper, not just a documentation file in a github repository.
[+] [-] bee_rider|1 year ago|reply
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 any evidence that any other websites need to be as interactive and dynamic as the tailwind website (they don’t).
Websites are all over-complicated, markdown is no curse. If this wall is true, it is a blessed line of defense.
[+] [-] gherkinnn|1 year ago|reply
It has nothing to do with complicated.
[+] [-] benj111|1 year ago|reply
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.
[+] [-] agnishom|1 year ago|reply
[+] [-] 0xbadcafebee|1 year ago|reply
There is a reason for that. And it's not because they're all stupid and software engineers are all geniuses.
It's because normal people do not want to spend their day wasted in minutia, carving out huge chunks of technical jargon, just to get some words on a page to show up with a certain layout and format.
They want to highlight some text, and click the Bold button, or maybe Ctrl+B, and see the text become bold. They don't want to write code. They want to just make a fucking document, so they can get on with their day.
We have had programs that do this for about 40+ years now. They are called word processors and presentation tools. They work very well, and require absolutely zero code or weird characters.
But software engineers are so insanely out of touch, so cluelessly locked into their web browsers, that they literally cannot imagine a universe in which a person isn't writing code to get some text to show up on a screen, formatted and laid out.
It literally feels like everyone in this industry is insane.
[+] [-] lmm|1 year ago|reply
> They want to highlight some text, and click the Bold button, or maybe Ctrl+B, and see the text become bold.
They do not. No normal person has ever said how happy they were that they could highlight text and click a button, and certainly not that they typed Ctrl+B. Normal people do not type Ctrl+anything.
Normal people don't type text at all, but if you find the most normie internet forum you can think of - one where people talk about car parts or who the Khardasians are dating or something - you'll find it has some kind of text markup format, and the most prolific users of that forum use the markup format rather than the WYSIWTF editor that craps up their formatting too much. And if you ever find a topic with two competing norie fora, you'll find the people on the one whose text markup format is more markdown-like will be happier than the people on the one whose text markup format is less markdown-like.
[+] [-] usr1106|1 year ago|reply
Just as an example: We use Google's office suite in our company because there are some users who believe it is more user-friendly than storing text and a proper version control. For version control Google offers named versions. Last week some Google sheet reached its 16th version. Well, would have reached, if Google did not limit the number of named versions to 15. You cannot run a business with serious audit trail requirements using so-called user-friendly "everyone uses" tools. Everyone has horrible standards and inappropriate IT continues to lower them. It's a fact, but not a fact anyone should praise.
[+] [-] scblock|1 year ago|reply
This is a really stupid take.
[+] [-] rr808|1 year ago|reply
[+] [-] herpdyderp|1 year ago|reply
This is exactly why I ditched WYSIWYG long before I knew how to code.
[+] [-] lgessler|1 year ago|reply
[+] [-] flkiwi|1 year ago|reply
The premise is deeply flawed. Richness is not a sign of care or investment in the reader's experience. Often it's exactly the opposite. Often richness is gaudy and pointless while simplicity makes content clearer and more useful. Maybe this is a great and valuable tool for certain use cases, but the justification here is weak.
[+] [-] ModernMech|1 year ago|reply
[+] [-] smcleod|1 year ago|reply
[+] [-] w10-1|1 year ago|reply
Markdown's chief feature is to be usable without tooling when writing, so more content is generated in the first place. So it extends the rich/cost graph to the left.
Because markdown is easily and often parsed, it operates as a data source from the get-go, mostly achieving the separation of concerns needed to scale to the right.
What are the pain or price points that will change with adopting this new technology?
(Is Swift-docc really the comparable? It seems to show what this is hopefully not: a subset dialect of markdown struggling with volatile, unusable hash links, no real extensibility or inter-op, tethered to BigCo's mission.)
(The curse of curses: they provoke negativity.)
[+] [-] groby_b|1 year ago|reply
Two, give us examples that live in that supposed wasteland. Without those, it looks like you're building a technology in the abstract. And, don't get me wrong, it's cool tech. It so tickles my sense of "fun engineering challenge, great way to express structure". But I've long learned that means it's also very likely in the "overengineered" corner.
I share your belief that there's a "there" there. (I'm on my umpteenth iteration of my own personal markdown, so I would ;) I think it'd be helpful to crystallize that into more concrete uses.
[+] [-] tristor|1 year ago|reply
Nothing about richness or leanness is implied or enforced by using Markdown for text, it's about everything else around it. On a statically generated page, you do it in Javascript, and render client-side if needed w/ data prepopulated in static objects. The only thing you can't do with a static page that ingests text as RST or Markdown or any other markup language, is something that requires dynamism with a backend database.
This is trying to blame Markdown and statically generated sites for leanness, but minimalism is a stylistic aesthetic choice people made that was a trend for awhile, it's not a requirement of the technology. The technology is just a tool.
[+] [-] quuxplusone|1 year ago|reply
> 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.
[+] [-] greggyb|1 year ago|reply
https://i.ibb.co/NryLFgJ/codehike-overlap.jpg
[+] [-] gklitz|1 year ago|reply
I think the author forgot to think about the content and got all invested in the display of their site. Should have just used markdown and spent the saved time looking for actual real data.
[+] [-] djoldman|1 year ago|reply
Why is asciidoc not more popular? It seems to support more than markdown and seems straightforward.
[+] [-] bluGill|1 year ago|reply
[+] [-] bvrmn|1 year ago|reply
IMHO article would be much better while not exploring new ideas and use simple text and web-native controls instead of inconvenient accessibility-wise poor UI/UX.
P.S. Print preview is hilariously bad.
[+] [-] Ayesh|1 year ago|reply
My solution is to fork the markdown tool I use to add my own tweaks. Some of the changes I added are:
- Vertical padding: Typically, `---` and `*` get converted to `<hr>` tags. I use `*` for `<hr class="small">` that has different padding top/bottom.
- Code examples with syntax highlighting.
- Block quotes with class names: `> {.warning}`
- Headers and table rows with support for setting a specific anchor ID: `# Header {#myId}`
- `<img>` tags with CSS URL matching to apply certain styles. For example, match `<img>` tags URLs ending with `#screenshot` will have drop shadow.
[+] [-] jfax|1 year ago|reply
[+] [-] jrm4|1 year ago|reply
[+] [-] impure|1 year ago|reply
Also is anyone building websites with markdown? I thought it was just a tool to format notes and blog posts. And even then you can insert HTML in it.
[+] [-] danbee|1 year ago|reply