Disclaimer: I'm biased as I created Scroll, but I can say pretty objectively that at this point it's far better than Markdown and the gap is only going to widen.
Try it out! https://scroll.pub/
We should have Markdown-rendered websites
271–280 of 351 posts
Re: We should have Markdown-rendered websites
#272Earlier quoted context omitted.
Alphabet is a 1T USD market cap, I‘m confident they could finance implementing 3-5 flavors.
I don't think money is the problem. It's the extra complexity to move markdown rendering from the control/responsibility of the server side, where it fits naturally, to the user-agent side, where it doesn't -- and for something that site publisher can already do (and evidently, rarely want to do).
I don't know why you say it doesn't fit naturally for the client to render a markup format. (With an RFC [0], too)
Chances are your client already handles a bunch other than HTML like SVG. Or even contextual ones like WebVTT.
Re: We should have Markdown-rendered websites
#273Earlier quoted context omitted.
Write a list in HTML and write one in Markdown. The difference in legibility is pronounced. Especially if you don't want weird whitespace things.
But why does it matter what the underlying code looks like to the end user? Nobody complains that the assembly code that runs their application is cluttered and illegible.
Yet people tend to choose python instead of assembly when introducing coding to a friend. It is easier to write, in part because it’s easier to read.
Re: We should have Markdown-rendered websites
#274Earlier quoted context omitted.
The primary goal and appeal of Markdown is that it is easy to write . Optimizing for parsing is creating a fundamentally different product. Standardization of the spec is good. Requiring quirky behavior and blank lines that hurt reading is bad.
Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before. > Requiring quirky behavior and blank lines that hurt reading Really? The linked spec says, referring to a blank link in indented lists: > reStructuredText makes the same design decision. And as a design goal: > your document [must be] readable just as it is, without conversion to HTML and…
> So my understanding of this part of the spec is confused (what does “interpret” mean?) but if it means no support for inline HTML that is indeed a pity.
The comparison to commonmark is important - it has special rules for HTML: https://spec.commonmark.org/0.29/#html-blocks
All its saying is that that djot doesn't have special rules for HTML so it spits out the same thing it receives, apparently with escaping relevant to the selected output mode. Note right above the part you quoted it shows an example of using HTML ("we simply do not allow raw HTML, except in explicitly marked contexts").
Re: We should have Markdown-rendered websites
#275Earlier quoted context omitted.
—I’d say it’s the other way around isn’t it? Wouldn’t Markdown be a subset of HTML, since all markdown can be expressed in HTML but not all HTML can be expressed in Markdown?— Edit: Markdown can contain HTML that gets meaningfully interpreted as markup as well. I’d also say HTML is not difficult to write, even for someone new to the concept. I don’t think anyone making their GeoCities homepage was too strained learni…
As far as I’m aware, you can write any HTML in Markdown, and it will be rendered normally. So Markdown can indeed contain any and all HTML. HTML can’t contain Markdown at all - a ### in HTML does nothing but a hello in Markdown does exactly what you expect it to.
> As far as I’m aware, you can write any HTML in Markdown, and it will be rendered normally.
It depends on your parser. Commonmark, for example, has rules for entering html mode: https://spec.commonmark.org/0.29/#html-blocks
Neither is truly a superset of the other.
Re: We should have Markdown-rendered websites
#276People are "big-picture" missing why this is an important idea. I had a prof put it like this once: The great tragedy of the web is the following: HTML made the web easy to read. But you know what made the web easy to write? Facebook. Facebook was undeniably the technology that made it so that roughly everybody could write things on the web to be read by everyone. I really like the direction of this, because it point…
LOL. Apparently I am old, but I remember the web before Facebook (or Google or…) existed. Everybody could (and many did) write on the web before Facebook. Geocities, My Space, or just create your own website. Believe it or not, but it was far simpler and cheaper to create your own website back then. There were tons of free hosting sites back then. You know what killed all of that? Facebook. This is why I am excited b…
I remember my first website experiment, hosted on "20megsfree". 20 megabytes of free hosting on a subdomain, they'd put an ad banner at the top, and you could pay for more / to remove the banner.
..and oh wow the domain still exists. Homepage is unchanged from 2001. Copyright line in the footer stopped updating in 2005 though so no idea if it would still work...
Re: We should have Markdown-rendered websites
#277No post body was provided.
Re: We should have Markdown-rendered websites
#278Earlier quoted context omitted.
Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?
I was a big supporter of SGML-based languages: markup language written for humans to author. However, the trend in computing in late 90s and early 2000s was to come up with more easily parsed languages, thus came things like XML: a mark-up language tuned for computers to produce. But let's be honest here: parsing most XML can be done very simply, whereas supporting basic SGML was only possible with the OpenSP. SGML i…
I have been on this journey since html 4 was coming out next year, and I’ve never ever heard of SGML. Wow.
I can see how JSON would be a reaction to that.
Re: We should have Markdown-rendered websites
#279Markdown is a convenient but deeply limited markup language with only a small subset of html's features. And yes, limitations are good because we want documents not web apps, etc, etc, but I mean "images can't have captions" limited, "navigation bars don't exist" limited. Actual important features of html don't exist in markdown, which is why almost every markdown platform ends up adding extensions and shortcodes. Wh…
Exactly what I was thinking, by omitting the and HTML can be quite concise [1]. Additionally the closing can be omitted from lists and barely a step over using - for bullet points. The worst part about HTML is the links, though. Anchor tags are awful. Having to repeatedly type and closing with is wayyy too boilerplate much for for something that is simply surrounded with [square](brackets) in markdown. [1] I go to ht…
I have the opposite problem. HTML links are consistent with the rest of the language. Something makes the same kind of sense as something.
But markdown? I'm always forgetting the order of the (link)[text] or [link](text) or [text](link) or (text)[link]. It's just something that's invented, and not consistent with the rest of itself.
Re: We should have Markdown-rendered websites
#280Earlier quoted context omitted.
This is nonsense. There were tons of things that made the web easy to write before FB. That is not what made FB successful. It was a combination of a lot of little features plus the big innovation that your profile had to be your real life identity early on. That was the thing prior social networks didn't do. It enabled the uniquely Facebook experience of being able to find past friends and more distant family.
> the big innovation that your profile had to be your real life identity early on. This came after facebook was wildly successful, so not early on. I also have never met a single person who was attracted by it, or was confused as to who their friends were before it existed. That being said, tying real names to online identity allowed facebook to buy data from brokers to fill out the sliced up audiences they sell to a…
> What made FB successful was that it was a platform that other developers could program for, so it filled up with games and quizzes. Farmville, "Which Harry Potter Friends Spice Girl Are You?" etc. was all the edge that it took to kill myspace, a site which seemed to stop any sort of development about 10 minutes after launch.
Even before that, it was a combination of exclusivity and social groups. When people found out there was a social network they weren't allowed into (when it required a *.edu email address to sign up for), they were curious and wanted in. For the people who could get in, Facebook had network pages tied to your email's domain so you had an immediate social group of people going to the same college/university as you, which was used for all sorts of things like planning events, coordination, sharing campus information, I believe it even had a full-on calendar for students to put things on.
The loss of the network pages was when I first started losing interest in Facebook.