# Modifying Kristall to Render text/plain Content

(created May 6, 2021)

In April 2021, I downloaded the most recent version of the Kristall internet browser.

=> https://github.com/MasterQ32/kristall/

Kristall can access Gemini, Gopher, Finger, and a limited http/https (no JavaScript nor external CSS). All sites across all of those application layer protocols look the same to readers, based upon the typography controls set within Kristall by readers.

I've been using Kristall since late last summer, and I like the recent updates. The latest version offers readers more typography controls.

Before building the new code, however, I modified one source file, making a tiny change in the following file.

* kristall/src/browsertab.cpp

My change:

```
else if (mime.is("text"))
{
    // jrs - 22apr2021 - downloaded the latest version of kristall
    // and then i commented out the one line below, and then
    // i added the text/gemini rendering code from above.
    // i want text/plain content to be rendered like text/gemini.
    // document = PlainTextRenderer::render(data, doc_style);
    document = GeminiRenderer::render(
        data,
        this->current_location,
        doc_style,
        this->outline,
        this->page_title);
}
```

Screenshot of the edited file with the above info:

=> https://live.staticflickr.com/65535/51159720927_b261e4385e_c.jpg

When I access files on Gopher and the web that are served with a MIME type of text/plain, I now see the content in a more reader-friendly view. Normally, Kristall displays text/plain content like a code block (monospace font). I want something nicer than that for text/plain content.

Since that was the only source file change that I made, raw URLs are not made clickable links in text/plain content, unless the text/plain content uses the Gemtext method of denoting links. 

Test file:

=> http://len.falken.ink/web/perceived-relations-between-gopher-gemini-and-http.txt

The image below shows how that post would normally display within a web browser. I'm using Pale Moon, and I increased the font size a couple notches to make it easier to read. In my opinion, it's fine to read text/plain content like this. It's more reader-friendly than most modern-designed websites. And since it's text/plain, the page loads fast.

=> https://live.staticflickr.com/65535/51160624733_eafd14402b_c.jpg

But I don't always want to read text/plain content as dark text on a light background with a monospace font. Within Kristall, I'm using typography settings that make a dark theme.

=> https://sawv.org/2020/09/28/my-typography-settings-for-the-kristall-internet-browser.html

This is how Kristall would have normally displayed Len's post, according to my typography settings. 

=> https://live.staticflickr.com/65535/51161175304_3e03ca6504_c.jpg

After my small edit to one source code file, Kristall now displays the page like this, according to my typography prefs. 

=> https://live.staticflickr.com/65535/51160624668_29bd77cb0e_c.jpg

It might be only a small improvement over how text/plain content is normally displayed, but it's enough that I prefer it this way.

Sometimes, Gopher users create their content pages in Markdown, and they get served as text/plain. Those files are easier to read now, in my opinion.

=> gopher://dataswamp.org:70/0/~lich/musings/links-browser.md

My own .txt Gopher post that consists of Markdown markup:

=> gopher://sawv.org:70/0/supporting-local-businesses.txt

The author at dataswamp.org saved his text files with a .md extension, and he used Markdown, but the content was served with a MIME type of text/plain. Since Gemtext is a subset of CommonMark (Markdown), then the Gemtext-Markdown similarities that exist within that post get rendered as if the text/plain content was served as text/gemini. 

Rendering text/plain content like it was text/gemini or text/markdown is more reader-friendly for me than seeing a large blob of monospace content.

It's unfortunate that text/plain content gets served only one way across the different application layer protocols in the browsers that exist. Jeesh, it's 2021. Why don't browsers permit readers to control the typography for text/plain content?

Here's how that dataswamp.org post on Gopher now appears to me when using my slightly modified Kristall browser.

=> https://live.staticflickr.com/65535/51162100666_f967a903bc_c.jpg

This is a screenshot of one of my Gemini posts that gets served as text/gemini.

=> https://live.staticflickr.com/65535/51161170214_ffbb7dbdd9_c.jpg

Within Kristall, content served as text/gemini, text/markdown, text/html, and now text/plain (for me) get rendered the same way.

Many times in older posts, I've mentioned how I have used Markdown rendering web browser extensions in Firefox and Chrome to display content served with the text/plain and text/markdown MIME types in a more reader-friendly manner.

This is Len's web post, displayed within Firefox and rendered with the Markdown Viewer extension. 

=> https://live.staticflickr.com/65535/51161490805_ef52ce449d_c.jpg

That browser extension renders files that contain extensions, such as .md, .txt, and more, and it permits adding custom file extensions that are not listed within the browser add-on. But the browser extension does not permit me to upload my own custom CSS theme. I had to choose a theme from a large selection of built-in themes.

I have used another Markdown rendering extension within Firefox that permits me to add my own CSS, but the extension only works with .md files. Some people, like Len and Gruber at daringfireball.net store their text/plain content in .txt or .text files.

I like the Chrome extensions Markdown Preview Plus because it permits to choose from a list of possible text/plain file extensions, including .md, .txt, and .text, and the extension lets me add my own CSS.

This is Len's post displayed within Chrome that uses Markdown Preview Plus and my own CSS.

=> https://live.staticflickr.com/65535/51159720957_f72d27e386_c.jpg

Kristall's point-and-click method of choosing typography settings is more user-friendly than having non-tech people create their own CSS, but the Markdown rendering browser extensions include themes that readers can choose. But I have not found a default theme that agrees with my prefs.

With the April 2021 version of Kristall, these are the typography controls available within that browser.

=> https://live.staticflickr.com/65535/51161493490_f7bb19505f_c.jpg

=> https://live.staticflickr.com/65535/51160627588_f036e4ae7d_c.jpg

In my opinion, Kristall is damn good software. After building the Kristall source, the resulting executable is 15.5 megabytes in size.

I've spilled a lot of ink in recent months, blabbing about the non-existent web subset or SmallWeb. In my opinion, Gemini is the solution to a desired SmallWeb. But if authors want to publish to the web, then an internet browser, such as Kristall, might be the proper tool to use, instead of a gigantic modern web browser with a browser extension. 

The other solution is to create a new web browser from scratch that only works with http/https content that is served with a MIME type of text/plain. This browser would provide readers with the ability to control typography like Kristall. Maybe the browser would include a simple, built-in feed reader too. text/plain web browsers could differentiate from each other by the typography options and other add-ons.

I guess that another option would be to use existing source code for browsers, such as Links2 or NetSurf, and modify these limited browsers to render text/plain content better.


In my opinion, the SmallWeb would consist of text/plain content, such as:

=> http://len.falken.ink/web/perceived-relations-between-gopher-gemini-and-http.txt

=> http://md.soupmode.com/2014/05/08/lesscrowded-toledo-area-birdwatching-spots.md

=> https://sawv.org/2021/03/11/quote-mar-11-2021-about-gemini.txt

=> https://daringfireball.net/linked/2021/05/06/more-on-night-shift.text

For text/plain-rendering web browsers, it could be optional to convert raw URLs into clickable links. No special markup syntax would be required to make the URLs clickable, but this could gum up code blocks that are not denoted by Markdown nor Gemtext markup. Converting raw URLs into links would be an option for readers to decide.

Another option might involve whether to preserve newlines or wrap them. Gemtext preserves newlines. Markdown to HTML does not preserve newlines.

Gemtext markup is small, easy to use, and non-intrusive, meaning that the existence of Gemtext markup does not interfere with reading the original text without rendering. 

=> https://sawv.org/2020/07/01/text-gemini-markup.html

Since Gemtext does not support inline linking, then the resulting content is easier to read in raw text form. Markdown, however, provides a nifty option to make inline links easier to read in raw form by using a footnote-like option where the URLs are listed at the bottom of the of raw text. But not every Markdown user uses this option. I rarely use it.

Over the past 10-months or so, I have been typing my web posts in Gemtext format or close to Gemtext.


The Medium Web would include sites, such as:

=> https://text.npr.org

=> https://lite.cnn.com/en

=> https://sawv.org

=> http://motherfuckingwebsite.com

=> http://john.ankarstrom.se

=> http://danluu.com


Medium websites use basic, easy-to-read HTML with no tag soup gobblygook. If the sites use CSS, then only a small amount of CSS is used. And no JavaScript, although some sites use Google analytics, which uses some JavaScript.

The Bloated Web includes everything else, which means nearly every media website is a part of the bloated web. These websites that are meant for reading use reader-hostile designs that force unsuspecting readers to download megabytes of cruft and crapware to read a few hundred words of text.

Web applications are another category. I use a so-called modern web browser for the infrequent times when I need to log into my bank account and my healthcare provider's portal. I login, perform some tasks, and get the hell out. 

Fastmail's web-based email client is a nice web application that I enjoy using.

But for reading, text-heavy sites should be faster to download and easier to read. I like text/plain web content, Gemini, and Gopher because no images get embedded within the pages. URLs can point to heavy content. This keeps the original content pages lightweight and fast-loading. This provides a more humane reading experience. Readers can choose whether to click the links for the heavy content. Too many websites embed images that are unnecessarily too large. 

I like the idea of a SmallWeb/web subset if it adheres to the text/plain concept with the display controlled by readers, not publishers. This is the default behavior of Gemini where authors focus on creating content and readers control how the content gets displayed.

If more people and orgs published their web content as text/plain .txt files, then Kristall could initially be the primary SmallWeb browser, provided that the Kristall owner made a couple small changes to support rendering text/plain content. Other text/plain web browsers would get developed. 

I can read https://text.npr.org fine with the Kristall browser. Kristall supports a Medium Web. It might be unnecessary for text.npr.org to create .txt text/plain versions of their content, but it could be a test case for the SmallWeb.

It's unlikely, however, that a text/plain SmallWeb paradigm ever takes hold. Even a Medium Web is hard to find.

Another version of the Medium Web, however, is based upon sites that place all of their content within their RSS and Atom feed files.

In my opinion, axios.com uses an annoyingly bloated modern web design. I like Axios as a media org, but I rarely read their content at their website. I read Axios within my own simple web-based and Gemini-based feed readers. 

I can also read Axios content within the built-in feed reader that's included with the Opera Mini web browser that I installed in 2018 on an old Blackberry phone that my wife received from work around 2010. 

=> https://sawv.org/2018/05/25/opera-mini-on-blackberry-classic-phone.html

It's not a Blackberry Classic. It's an old Blackberry that I called classic. Uppercase Classic was a later model.

This week, I started using that Blackberry phone again, and it still functions fine as a small, WiFi-enabled, internet reading device. I can read Gemini content on the Blackberry by using Dew Devault's web proxy to Gemini.

=> https://portal.drewdevault.com/x/sawv.org/

Anyway, sites like Axios that place their content within feeds can be read in a more humane manner by using feed readers, instead of visiting those sites directly. This is sort of Medium Web-ish.

I don't place all of my content within my website's RSS file, but that's mainly because my website is Medium Web by design, and my posts can be quite long.

Len's website and most Gemini authors do not place their content within RSS and Atom feeds because readers know that text/plain and text/gemini sites will be safe, sane, fast, and reader-friendly by default.

In this post:

=> https://sawv.org/2021/04/21/smallwebish-hn-chatter.html

I listed a few things that could comprise the SmallWeb spec for authors and browsers. This is my new, slightly modified version.

* browsers should provide the option to either preserve or wrap newlines.
* make URLs clickable links, provided that the URLs start at the beginning of lines, and only one URL exists per line. it would be similar to Gemtext but minus the equals sign plus greater-than sign, used to denote links.
* browsers should provide the option to convert ALL raw URLs to links, regardless of where and how the URLs are typed.
* no inline linking with link text. 
* offer some optional formatting markup capabilities, like Gemtext.
* no image embedding. authors can list URLs to heavy content.
* no forms processing, which means only static content.

It's text/plain content with newlines preserved and URLs converted to links. If optional Gemtext markup is used and supported by the text/plain browsers, than that's a bonus. Personally, I like having blockquotes, headings, ordered-lists, and pre-code blocks rendered for easier reading, but it's not a necessity for that to occur.

When a plethora of personal web publishers display their content as text/plain, instead of text/html, then I'll be shocked and pleased. This would require new text/plain web browser development. Maybe it's a chicken-and-egg thing. Which should come first?

If a text/plain SmallWeb did form, then I'm guessing that SmallWeb ankle-biters would say, "Why not use Gopher or Gemini, instead of publishing web content as text/plain?" 

Today, Gemini ankle-biters say, "Why not use a web stack from the 1990s, instead of a new application layer protocol?"

Fun stuff.

The website len.falken.ink is the only text/plain website that I'm aware of, but I have visited hundreds of Gemini and Gopher sites. That's tiny compared to the web, but it's still more content than I have time to read, and both are attracting new authors. 

This is fun:

=> https://tilde.club/

But the content is HTML, at least what I have seen. tilde.club sites or spaces could be considered Medium Web.

My text/plain SmallWeb idea and the web subset ideas proposed by others are only that: ideas. Gemini, however, is real, and it's nearly two-years-old with significant support by programmers, writers, and readers.


-30-

``` dir : 2021/05/06
```