Markdown-only Web Browser

created Jan 22, 2019

Instead of creating HTML pages, websites would create plain text files that use simple Markdown formatting. A web browser would fetch the Markdown pages, and render them for display.

At the moment, I do not have a standalone, native, desktop browser app that does the above. I'm relying on web browser extensions.

Both extensions permit me to upload custom CSS, which allows me to display the Markdown files however I desire. If other websites published Markdown files, then those websites would be displayed according to my custom CSS.

Every web page for every website would look the same TO ME. It would be similar to using "reader mode" functionality that exists with some web browsers, which makes every web page look the same.

All books look similar when viewed on a Kindle.

For web article pages, I'm disinterested in site wide header and nav areas. I have no interest in the crap displayed in sidebars when articles are viewed on larger screens. My focus is with the text that's contained within the body of the article.

I understand the desire and fun for quirky creativity when making funky web pages, but the content is still the main reason why I read most websites. Content is the interface.

I prefer to read, which means that I like text. A smattering of useful images are fine too.

Readers should be in charge of choosing the styling and typography for how web pages get displayed. Website owners create default looks that will hopefully appeal to most readers.

But while I prefer a larger font size, others prefer a microscopic font size for some odd reason.

And while I prefer high or semi-high contrast between text color and background color, others, apparently, prefer light grey text on a light grey background with a microscopic font size, of course, when viewed on a phone. WTF?

And it's wonderful that some of these painful-to-read websites prevent zooming in to increase the font size when viewed on a mobile device. This is a hostile web reading design. Hence the need for reader mode functionality.

"Reader mode" that exists within web browsers (Safari and Firefox) or as browser extensions (Chrome) are nice, but they don't permit enough customization.

Sadly, some web pages aren't available for reader mode, or the pages lose content when viewed in reader mode, probably due to an unnecessarily complex web design abomination.

Display and/or typographical features that I like to control include:

Regarding the Markdown viewer web browser extensions, I'm guessing that most readers would not create and upload their own custom CSS. Both extensions, however, provide built-in themes or default displays, which work fine. More theme options would be nice.

Here is my test website that uses my simple web-based static site generator called Sora that has been slightly modified.

http://md.soupmode.com/home.md

Here's the CSS that I uploaded to the extensions. (updated as of Feb 5, 2019).

body {margin: 0 auto; max-width: 680px; font-size: 22px; width: 100%;  line-height: 35px; color: #222; background-color: #fffff6;}
body {font-family: system-ui, -apple-system, BlinkMacSystemFont, "San Francisco", "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", "Lucida Grande", Verdana, "Helvetica", sans-serif;}
img {max-width: 100%;}
pre, code {font-size: 16px; background: #fff8dc; overflow-x: scroll; overflow-y: hidden;}
p {margin: 40px 0 40px 0;}
h1 {font-size: 35px; margin-top: 20px;}
h2 {font-weight: 400; font-style: italic; font-size: 30px;}
h1,h2,h3,h4,h5,h6 {line-height:1.2;}
h3 {margin-top: 70px;}
blockquote {background: #E3F2FD; margin-left: 15px; padding: 0 0 0 15px;  border-left: 1px solid #666; }
@media print{body{max-width:none; color: #000; background-color: #fff; line-height: normal; font-size: 18px;}}
@media only screen and (max-width: 680px) { body {max-width:92%} }
li {margin: 10px 0 10px 0;}
a:visited {color: purple;}
a {color: blue; text-decoration: underline;}

Feb 6, 2019

HN thread that pointed to this tweet:

"Why do I need a 4Ghz quadcore to run facebook?" This is why. A single word split up into 11 HTML DOM elements to avoid adblockers.

Pretty soon, it will be faster and more efficient to just send us prerendered bitmaps.

I was more interested in the replies by Stefan Werner.

I think we’ve already reached that point. Most web pages would be smaller and faster if they we just plain PDFs. Also, they’d work in every browser.

We flew to the moon 50 years ago, but still can’t figure out how to render text. The internet in 2019.

To be honest, I don’t want web pages to render the same everywhere. The initial idea of HTML was to let the client side handle formatting. The page says what's a header and what's a footnote, the browser/user gets to decide what font or colors to use for headlines and footnotes.

Instead we got the patronizing web. One that jumps though hoops to impose fonts and colors on you, regardless of impaired vision or screen resolution.

Apr 16, 2019

This is interesting. It's an HTML page, but the content is Markdown, surrounded by pre tags, and JavaScript renders the Markdown as a formatted page. Without JavaScript, only the Markdown is displayed.

https://jott.live/markdown/telnet_writeup

https://github.com/bwasti/jott

That jott.live post uses marked.js.

https://github.com/markedjs/marked

That JavaScript uses relatively new concepts because when I view that page on my old iPhone that uses iOS 8.x, I see only the Markdown even with JavaScript working.

Jul 3, 2019

webpagetest.org results for a test plain/text file that has a .md extension.

http://md.soupmode.com/2018/05/25/opera-mini-on-blackberry-classic-phone.md
From: Dulles, VA - Chrome - Cable
7/3/2019, 9:11:37 AM
Time: 0.264 seconds
Requests: 2
Bytes in: 2 KB

The client-side web browser is responsible for the time to render the Markdown into human-consumable viewing, which is obviously what web browsers do now with HTML text. My example uses Markdown text, which is text/plain.

The reader can control how the pages get displayed by either choosing default CSS themes that come with the browser extension or by uploading a custom CSS theme. I choose the latter.

Jul 4, 2019

"User Inyerface – A worst-practice UI experiment (userinyerface.com)"

https://userinyerface.com/

https://news.ycombinator.com/item?id=20344565

I'm guessing that it's some kind of joke to make a point about horrible website/web app UI/UX these days. ???

I posted the above because of this HN comment:

It boggles the mind to think of how much resources (time and money) have been spent so that control freak corporations can control my user experience from the server when I have a rich client under my control.

The whole web is backwards these days; users should’ve able to download themes for different kinds of content and the content itself should be barely human readable self-describing text with no layout instructions *only hints (like title and h1 and p)- *leave it to the client to choose how to display.

More than ever, I would like to create my own web browser that is obviously built upon something else. The browser would not need JavaScript. Heck, if the browser did not support HTML5 and CSS3 that might be okay too.

I like the control offered by the Chrome Markdown viewer extension. Both the Firefox and Chrome extensions permit readers to upload their own CSS to theme the pages. This makes my web pages and the Daring Fireball pages look the same.

It would be nice if the web browser permitted the option to use the same theme for all websites and to use themes for individual websites. The theme chosen for my website would appear different than the theme that I chose to use for daringfireball.net's Markdown pages that end in .text.

Example HTML page at Gruber's site:

https://daringfireball.net/2019/07/on_the_post-ive_future_of_design_at_apple

To view the Markdown version, add .text to the end of the URL.

https://daringfireball.net/2019/07/on_the_post-ive_future_of_design_at_apple.text

Another reader could choose a different theme to read my website. People could share the themes that they created to view websites, instead of sharing how their websites appear. The readers decide how websites look for themselves. The main thing is the content.

It would be a funky web if no HTML existed on the server. Is is still the web? Hell, yeah. If web URLs can point to PDF files, images, and videos, then Markdown text/plain is still the web, since the text is served over the HTTP/HTTPS protocol.

The web browser can convert the Markdown text/plain to HTML text, which the browser can render for the reader to understand. The browser would apply the CSS theme, chosen by the reader. This would happen as fast and most likely faster than the modern web today, since most modern websites are massively bloated poop piles.

When only text/plain can be processed by the web browser, then the pages and websites are more secure for the readers. No crapware gets downloaded because JavaScript won't exist.

If HTML tags are used in the Markdown text/plain files, then the Markdown conversion code that exists on the client-side as either a browser extension or native to a custom built web browser would convert those HTML tags to entities, which means the HTML tags won't work.

I think this would be a slightly prettier version of Gopher.

I believe ads could still occur, since it's possible to embed an image within Markdown. I reckon that the image URL could point to a server-side program that would dynamically create the binary image content.

Also, I reckon that the Markdown text/plain files could be dynamically generated. They don't have to be static files. The web server needs to send back text/plain, and the URLs would need some kind of extension.

I don't think this would work:

This might work even if it's dynamically created:

Simple test. This is an HTML page that is dynamically generated or it's pulled from Memcached.

http://nuthatch.soupmode.com/test-post-21sep2019-1417

Adding .md to the end of the URL caused the Chrome web browser Markdown extension to try to process the page as Markdown, even though the web server would have sent back text/html. Interesting. But the Markdown browser extension converts the HTML tags to entities, rendering them useless.

http://nuthatch.soupmode.com/test-post-21sep2019-1417.md

Here's a better example of a dynamically-generated page that produces Markdown.

My Grebe CMS stores content in a database and also in Memcached. Unlike my Nuthatch app shown above, Grebe has an option to show the markup source for a page. The markup is pulled from the database and dynamically sent to the reader. The "source" link is displayed at the bottom of each post.


Another Jul 4, 2019 update in the mid-afternoon on a warm, very muggy day.

At archive.org, I dug out a Perl script that I wrote back in 1998. It's a CGI program that displays an image every nth interval.

I called the program impint.pl

http://sawv.org/2019/07/04/my-updated-version-of-impintpl.html

I mentioned the Aug 16, 1998 weather in the comments of that script. Here is Toledo's weather at about an hour ago.

Toledo Express Airport (KTOL)
Jul 4, 2019 2:52 pm EDT
Weather : Fair
Temperature : 91 F
Humidity : 52%
Wind Speed : WSW 10 mph
Barometer : 29.98 in
Dewpoint: 71 F
Visibility : 10.00 statute miles
Heat Index : 98 F

Test URL. Every second time, the image is displayed, otherwise a single pixel is returned.

http://testcode.soupmode.com/cgi-bin/impint.pl?interval=2&gif=one.gif&dotcolor=FFFFFF&name1=mrx&name2=test

I updated this Markdown post to include two of those URLs, each sourcing a different image. One image will be displayed at a time, and the images will alternate.

http://md.soupmode.com/2019/06/24/the-plastic-conundrum.md

Image ads can be displayed within the Markdown text/plain posting world, since the image function can reference a server-side program with args that can determine how the image is displayed.

What about cookies being set in a custom web browser? If using a web-based CMS to create and update the Markdown text/plain files, then cookies would be needed to manage the login session.

Since it's possible to dynamically create Markdown text/plain files on the fly on the server, then the server could also send cookies to be set. ??? The humidity combined with this discussion is making me dizzy.

An actual customized web browser could limit cookie usage. Obviously, the full range of cookie abuse would be available when using the browser extensions with the lovely modern web browsers Chrome and Firefox.

Aug 14, 2019

"Show HN: Yack – Community Browser for Hacker News, Reddit, YouTube and More (yack.io)"

https://yack.io

https://news.ycombinator.com/item?id=20687398

HN comment:

This looks like what I've wanted the web to be for years now. It's the best parts of RSS, Gopher, and the web.

What's terrible about the modern web? Mountains of JavaScript, for trackers, and advertisements, and custom UI so every page acts differently (and slowly) even though they're 99% the same. This appears to cut through that crap, and just give me easy access to articles and comments.

I want just a 'web browser'. What we've got today are network-native application runtimes that happen to run over the web. There are some cases where that's good, but for "reading an article", it's somewhere between "a waste" and "a channel ripe for abuse".

You talk about bookmarks, tabs, history, etc. I rarely use those for articles I see on HN. I use web browsers for a few very distinct use cases. (They just all happen to be delivered over the web because, I don't know, nobody wants to write applications any more.) "Reading an article" doesn't require bookmarks/tabs/history. I read it, and then I'm done.

I don't use web browser bookmarks either, since I use browsers on multiple devices. I'm not interested in bookmark syncing if it exists. I use different web browsers across my different computer devices. When I want to save a link, then I store it here on my own website.

I mostly read HN in Private Browsing specifically so it doesn't litter up my history with some article I only want to see once. I mostly use Reader Mode, when possible, because I don't want any other junk besides the article. A full 2019 web browser for reading an article is a liability, not a feature. I rarely follow any links from them.

Chrome and Firefox are massively bloated for reading web articles the way that the above person and myself prefer to read on the web. links2 -g works better. It's faster and smaller than Chrome and Firefox.

More from that great HN comment:

Saying that one needs to "configure an ad blocker" to read articles on the internet almost sounds like an admission of failure.

Damn right.

My post http://sawv.org/2019/05/13/complex-bloated-web-design-described-in-13-words.html that excerpted from an HN comment, which said:

I love how browsing the web now is like gearing up for war.

Back to the Aug 14, 2019 HN comment:

There shouldn't be an "inexorable" drive to make this into a full web browser, any more than there is for an email program. Email programs display HTML and let you click links, too.

Unfortunately. Enabling HTML to work within email is a great tragedy, led by corporation shitheads.

They are specific to one type of data, and display it using native controls. Nobody is browsing the web in Mail.app. They are browsing the web in their regular browsers, for the types of online experiences that require that.

Another comment from that Aug 13-14, 2019 HN thread:

We need a web anti-browser, which only has a "reader mode"

-30-