Docsify already does this.
We should have Markdown-rendered websites
331–340 of 351 posts
Re: We should have Markdown-rendered websites
#332Earlier 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…
> This came after facebook was wildly successful, so not early on.
Not true. The original version of the site required you to be a student at Harvard, then a student at select universities, etc. Eventually it opened to the general public, but the norms for Facebook had been set. You entered your real name, real city and state, real college, etc.
You also misread what I said this allowed you to do.
Re: We should have Markdown-rendered websites
#333Earlier quoted context omitted.
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.
HTML4 was the last of "HTML-is-an-SGML-application" (that was the terminology when you define a document type with a SGML DTD) attempt before XHTML 1.0 came out.
SGML is what allows implicit closing tags, for instance.
Of course, even XHTML failed because it was too strict and browsers couldn't trust websites with following it to the letter, so we ended up with HTML as of today: clearly coming out of both, but not really either of them anymore.
Re: We should have Markdown-rendered websites
#334Earlier quoted context omitted.
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…
Me, too, having worked at IBM and used SGML there. But JSON is what really killed XML. It can be harder to read, especially at first, but it's shorter and fulfills all the same roles.
I wouldn't say JSON killed XML: it's still widely in use for documents whose type definition changes rarely and which are more content oriented. The one benefit to XML/SGML languages is that you've got simple, ubiquotious support for "attributes", plain text content and nested tree content.
I.e. to represent
An HTML page was the driver for interactive web.
[
{
"type": "p",
"content": [
{"type": "STRING", "value": "An "},
{"type": "acronym", "attributes": {"expanded": "HyperText Markup Language"}, "content": [{"type": "STRING", "content": "HTML"}]},
{"type": "STRING", "content": " page was the driver for interactive web."}
]
}
]
So with JSON, everyone comes up with their own format. And in these cases that XML was designed for (to mark up textual content), it handily beats JSON in expressiveness, simplicity and terseness too. The fact that it was misused for defining protocols and objects (i.e. SOAP, ugh) is a different matter.
I would say that SGML/XML languages still have this benefit over even Markdown: any contextual modifier is either impossible or uses a one-off syntax (like images or links with text).
Re: We should have Markdown-rendered websites
#335Earlier quoted context omitted.
> only a small subset of html's features. On the contrary - Markdown is essentially a superset of HTML, so unless you're using a renderer that strips it from the input, you can have the best of both worlds. This property was super useful for a lightweight CMS I threw together a few years and which is still used by the original customer today. 99% of what they need to render is easily authored in Markdown, and this fu…
The original markdown parser supported html because it was basically just a preprocessor that added some syntactic sugar to html. The proposal here isn't just "what if browsers had a markdown preprocessor" (although I also think that would be questionable), but "what if browsers limited content down to only markdown, so that the web was all just clean, style-agnostic documents," and that clearly requires that markdow…
Having re-read the article, i must say that this is another incorrect claim. It proposes no such thing. This is one straw man after another.
All it actually suggests is this:
> Let's have markdown rendering in all major browsers soon
Re: We should have Markdown-rendered websites
#336> "towards a presentation-independent data format for text"
Wikitext is more suitable than Markdown for this role though less ergonomic.
Re: We should have Markdown-rendered websites
#337Earlier quoted context omitted.
Me, too, having worked at IBM and used SGML there. But JSON is what really killed XML. It can be harder to read, especially at first, but it's shorter and fulfills all the same roles.
I wouldn't say JSON killed XML: it's still widely in use for documents whose type definition changes rarely and which are more content oriented. The one benefit to XML/SGML languages is that you've got simple, ubiquotious support for "attributes", plain text content and nested tree content. I.e. to represent An HTML page was the driver for interactive web. in JSON, you have to come up with your own conventions for at…
Indeed. And I do miss XSLT. There's nothing like that for JSON.
Being document oriented from its SGML roots, XML always had more markup, rendering, and search options than JSON.
Re: We should have Markdown-rendered websites
#338Part of the benefit of Markdown is that you can view the raw source and still get useful info out of it. But this site prerendered the Markdown and served HTML which defeats part of the purpose. A better option would be to use something like https://casual-effects.com/markdeep/ and serve the MD/HTML file. Then you can get a client-rendered HTML ( https://casual-effects.com/markdeep/features.md.html ) or view the raw…
These websites didn't render for shit on my mobile. I had to zoom in and out.
I'd never subject a reader to this kind of horrible UI.
Re: We should have Markdown-rendered websites
#339Earlier quoted context omitted.
Agreed, original HTML was not too different than markdown really. (But more standard, and slightly more powerful with things like tables, code blocks, and definition lists, all of which are only non-standard extensions to markdown!) Maybe what OP really wants is a lot more people to write HTML without _any_ CSS or Javascript. But that's already more or less available, so there are reasons people don't do it to grappl…
> Perhaps a mode where you tell the browser to ignore any CSS or Javascript; possibly also in this mode the browser could use better more readable standard html rendering, similar to what most markdown renderers choose by default (bigger font sizes and line-height, more and more even whitspace around headings, maximum page width, etc), instead of the legacy choices they are now sticking with for backwards compat. Isn…
Reader mode also attempts to discard "unimportant" content – if you intentionally enter reader mode, it's fine to discard even things like the page navigation, but not so much for a browser's default mode.
Plus sometimes it's too overeager and discards content that shouldn't actually be discarded (e.g. I'm hosting some radio show transcripts, and with my markup Firefox's reader mode discards the bit of text indicating who's actually speaking).
Re: We should have Markdown-rendered websites
#340Earlier quoted context omitted.
When you say rendered on demand, you mean by the client, as in a page request? Why not just rerender to HTML on developer change? Genuinely curious why rendering on demand is preferred in this case.
> ... as in a page request? Yup. > Why not just rerender to HTML on developer change? Because that's not how the Fossil SCM renders content. It has a cache, but only for certain high-CPU data like generation of zip files of the source tree. Caching markdown docs wouldn't work in all cases, anyway: when you link to a ticket, for example, it gets rendered differently depending on whether it's opened or closed. Thus the…
Well, the more you know. Thanks for the detailed reply.