Skip to main content

Markdown vs HTML

Markdown converts to HTML. It’s designed to do that. But it’s drastically simpler in form than HTML. What if we could replace HTML altogether?
Right now, Markdown is built to support HTML directly. So to support Markdown is to support all of HTML as well. What if we just remove the HTML support and build Markdown as the language the browser understands natively?
Benefits:
  • Markdown is far easier to read than HTML.
  • It’s far faster to parse, no open/close tags.
  • Smaller file size; since there are no open/close tags.
Tying in with the proposal to code in English, Markdown would provide a familiar, written form to compliment the English language.

CSS and JavaScript

Both CSS and JavaScript can be included using code blocks.
  body { background: white;}
  console.log('This will be executed.');

Further Consideration

Various projects already exist to simplify use of Markdown either within HTML or by using an HTML page for boilerplate and Markdown file(s) for content.
Consider this: https://news.ycombinator.com/item?id=18154825
GitDown was designed to do roughly the same thing. There are others as well. But like GitDown, Markdown page simplifies everything to the point that forking the repo on GitHub and then editing the relevant Markdown file(s) results in a ready-made web page.

Comments

Popular posts from this blog

OpenGL Everything

Recent terminals like Alacritty and Kitty have proved OpenGL is the fastest way to handle text rendering. Xray, the potential next generation of Atom text editor rightly seems to follow suit. Meanwhile, Linux distros like Ubuntu have long been using OpenGL for general rendering to great success as seen with compositors like Compiz.It seems OpenGL might be the best technology for any and all rendering needs. If an OS is built on and uses OpenGL for everything, the consistency could yield great results. Text editing, image manipulation and even office apps would be as fast as possible.

Everything Text

Pixel and vectors, video and text. What if we built one editor that could handle all these cases and more? One editor using one human-readable text format for files. If we use Markdown, we can use code blocks to represent binary data, if needed. Besides being able to store binary data, we could create human-readable data sections using formats like Eno. We could even include executable code.  With the flexibility of Markdown and its respective code blocks, we could store any type of data in a manageable way. So the file format for our all-purpose editor is plain text, Markdown.

We'll build our editor for text processing. But from the start, we must account for all editing needs. We're building a text editor that can do what Photoshop does, and what Premiere does. So first and foremost, everything those editors can do, our editor must be able to do using plain text. From there, we can create intuitive graphic interfaces to facilitate different workflows. Those UIs will basicall…

The Text Editor

Text editing comprises the core of an operating system. Every OS ever provides some way to edit text. Even the terminal or commandline is a text editing experience. We should build the best possible text editing experience into the OS.Temple OS as inspirationIn Temple OS, the text editor is everything. The commandline is actually a programming experience since commands are compiled as they’re entered. Meanwhile, a special document format (DolDoc) lets users structure text for easy navigation similar to HTML but better because of the way it links to other documents. That’s all part of the same core text editing experience. And that experience distinguishes Temple OS. The text editing experience is all its focus.Markdown for powerIf we use Markdown for structured documents similar to Temple OS’s DolDoc format, we can advance it steps further by allowing code execution via code blocks. Code blocks are executed when documents are opened for viewing. We can use that same concept for any an…