/~bencollver/log/2024-02-19-gopher-formatting on tilde.pink

	View source

	# 2024-02-19 - Gopher Formatting

	I've been reading posts in the gopherverse with opinions about how to
	format gopher content. I figure part of the appeal of gopher is that
	its design pre-dates the commercialization of the Internet. Likewise
	in that era the Internet was flying under the radar. It had room for
	ideals like anarchy, decentralization, and dissenting opinions.

	A year or two ago, i read strong opinions about how to format content
	for gopher. The two main positions are A) RFC1436 and also reference
	client only display 70 characters of text, so hard wrapping is polite
	and preferrable, and B) mobile devices are the new normal and content
	should be designed for mobile users.

	I sat and thought for a while, and it occurred to me that web browser
	tech doesn't care whether you hard-wrap text. It re-flows / re-wraps
	the text to fit the display. Long lines, short lines: irrelevant. I
	wrote a proof-of-concept script to hard wrap and unwrap text and then
	ran it to convert my site from gemtext to gophermaps and back. After
	seeing this successful round-trip, i hard wrapped my content and have
	not looked back. I also wrote algorithms to split long URLs in a way
	that is human readable and join them back together into working links
	in gophermaps.

	So far as i am concerned, it is a contrived dichotomy, a rare & happy
	circumstance where there IS a technical solution. It's way easier to
	change software than to change minds.

	There are drawbacks to using a protocol designed in an earlier era of
	the Internet, too. For example, internationalization was clearly not
	a design goal. Here too, this is a happy circumstance where there is
	a technical solution and most client software has already implemented
	it. Just take the spec and replace the word "Latin" with "UTF-8".

	Recently i wrote a script to validate gopher maps. When reporting on
	potentially problematic gopher text, it gives references. One of the
	things it reports is using gopher maps for content, versus navigation
	as some clients cannot be used in this way. I totally understand why
	people would want to use gopher maps for content. This preserves the
	familiar metaphor of hypertext that blends links inline with content,
	as is done on the web.

	Here i do not see a happy technical solution. Either i use gopher as
	it was originally designed, and i separate content from navigation OR
	i can approximate the web experience and exclude users of old classic
	computers and software of that era. As a workaround, i put a link at
	the top of my content to "View source," which in my case is plaintext
	markup that my script converts to a gophermap. My gopher maps do not
	pass my own validation script, but they ARE viewable in UMN gopher by
	using the "View source" menu option.

	Below is a link to my validation script in case anyone is interested.
	I welcome feedback!

	gopher-validate.awk

	tags: bencollver,retrocomputing,technical

	# Tags

	bencollver
	retrocomputing
	technical