Spacing is a challenge. And you lose some legibility giving up proportional fonts. I think kerning in proportional fonts makes a big difference, letting your eyes recognize the shape of different letter groupings.
Monospace text is fine if you avoid long-form text, like when it's structured and highlighted in a code editor.
But it sure is pretty! Especially with Unicode charts and ASCII art.
15 space, 1 V, 3 U, 1 V
15 space, 5 U
12 space, 2 x, 5 U, 2 x
and then after 250 lines, a pic of Jordan dunking would show up once done and we could print it!
I agree, monospace without color and some formatting is like giving up a sense or spatial dimension. It's pointless austerity.
I gave this some thought in the past, and, since this is more of an artistic/crafting endavor than anything else I'd say we decide on some arbitrary rules (like "only monospace fonts, no external javascript, only static content", I don't know, I'm just spitballing here) and create our own certification to display at the top of the page (like the omnipresent top-right oblique ribbon of yesterdecade or, even better, the little badges we used at the turn of the century), then we make a central list where people can add their website.
Anyone know what I'm talking about and have a link?
[0] http://www.catb.org/esr/jargon/html/B/bricktext.html (Also wow Google has completely erased this concept from its search results.)
http://www.catb.org/esr/jargon/html/crackers.html
On C64 the signs of puberty were usage of words like “lamer”, “loser/looser”
Loser vs looser was especially painful. “Haha, we know it’s loser but looser sounds cooler.” A lame cover up, somewhat contradicting the whole meaning.
90% of the scroll texts were about contrived stories of displaying superiority over lamers and losers.
The folks from Finland appeared to be a bit over the top with references to their weight lifting careers to appear like some sort of brutal fighting machine.
Kids back then… ;)
For me, it replaces the search with "brick text", but allows you to change to "bricktext" again, at which point it does give the catb.org result.
I actually got an angelfire link in my search results a few days ago. Was related to quake 2
https://github.com/laravel/laravel/blob/11.x/config/database...
https://gamefaqs.gamespot.com/snes/588741-super-metroid/faqs...
For years I wanted to make a Visual Studio [Code] extension that justifies comments as you type including hyphenation but accepting additional spaces as necessary. I never dared to really start beyond some research into relevant algorithms and libraries because it seems pretty complex. I tried to use things like fmt and par but mostly accepted that I can not have nicely formatted comments unless I do it manually, which I do sometimes but in general just costs to much time, especially as any small change often forces redoing several lines.
You have to deal with long identifiers that you preferably do not want to break across lines, [nested] lists, tables, code blocks, or ASCII art contained in comments, distinguish between hyphens as part of words and hyphens inserted by hyphenation, there might be structured comments like XML doc and Javadoc tags, ... When I saw Tom7's Badness 0, I considered throwing a LLM at the problem, but I think that this is not [yet] practical if you want it in real-time and without hallucinated comments.
Does something like this already exist or something to build on top that would make writing an extension not a year-long effort?
I use this extension extensively. It's not auto-wrapping, but you can bind it to an easy shortcut and wrap when you need to. I find it almost indispensable. I wrote a vscode extension to do the same thing, then discovered this one which does it far better.
Is the hard line endings that bother me.
Someone with their "retro" web site that, essentially, uses pre tags.
You get a wall of text, in a small font on the phone, reader view doesn't work, and if you tilt is sideways, you're as likely to get scrollbars as not.
Nowadays this is also my singular complaint with tech mailing lists. The hard line endings and rigid layout.
All I get in response is “we’ll just (it’s always “just”) solve that with <insert expensive AWS service here>”. No-one seems to acknowledge that that only makes things more complex.
I definitely prefer this to the "beautiful" pages that try to capture the feel of old print magazines.
Conversely, for reading Markdown, I prefer a rendered version in a proportional font.
So both have better "readability" in different ways. Faster/easier or more accurate. Which implies to me at least that mono is better for everything but body text even when things are ideal. I don't think it is possible to have a single proportional font that works for both definitions of the word "readability".
On modern high density displays serif fonts can also work fine. But not all displays out there are actually of that high density.
That's just one aspect though. There has been a lot of research over the years which for some reason is often ignored.
I was about to write out a lot more and while looking up various sources stumbled upon a medium post that dives into things quite deeply: https://medium.com/@pvermaer/down-the-font-legibility-rabbit...
That’s the problem with using the same character grid for both graphics and text. It could be alleviated with a font that has a particularly low x-height (leaving more margin above and below the letters).
The line height, I agree, is too tight. 19.2px at 16px font size is too cramped at only 1.2x. Making it 24px is a big improvement.
To my eye, however, a taller line height doesn't affect the tables and other character graphics. With some tweaks like this I think the monospace style comes across quite well.
* edit - I think I see your point; it does break the author's concept of the fixed grid (set line-height: 24px for p elements and turn on the author's "debug mode" to see the grid.
javascript: (function() {
(function() {
const textElements = document.querySelectorAll('p, span, h1, h2, h3, h4, h5, h6, li, td, th');
textElements.forEach((element) => {
const textColor = getComputedStyle(element).getPropertyValue('color');
element.style.fontFamily = 'system-ui, -apple-system, sans-serif';
element.style.WebkitTextStroke = `0.4px ${textColor}`;
});
location.hash = "";
history.replaceState("", "", location.pathname);
})();Joke. Cheers! ;)
(due to monospace words have a more similar 'shape' than proportional type words)
It's a pity that there isn't a TrueType version.
Can you use the OTF files instead? Their readme says there are OTF files in the release tarballs.
https://www.cebix.net/VIC-Article.txt
Main issue is printing.
The article uses a diagram that needs fixed references in a two dimensional space. That’s why monospace here is invaluable.
The article is the single most important technical reference for the C64. 99% of all technical demo effects can be broken down to fundamental tricks found here.
Anybody know which ones are particularly good for long-form text readability?
Bonus points if it's on Google Fonts.
Not on Google Fonts but it's free (or very cheap for the variable version).
You get the upsides of being able to pick a nice font from Google Fonts while not having the downside of tracking. It also helps with caching! And also prevents the font from disappearing for no reason.
/*
Character Variants settings for JetBrains Mono
(All are off by default, left them here all for reference.)
H/T https://wakamaifondue.com/ for the inspect!
This set is pretty much like "ss01" but with "cv07" on
or like "ss02" but with "cv05" off
"id" state `affected glyphs` effect when enabled (my pref/note)
*/
font-feature-settings:
"zero" off, /* `0` slashed, instead of dotted */
"cv01" on, /* `l` flat serif bottom instad of curve (on!!)*/
"cv02" off, /* `t` bottom curve instead of hook */
"cv03" off, /* `g` double-storey (sadly not nice) */
"cv04" off, /* `j` rounded bottom hook */
"cv05" off, /* `l` rounded bottom hook */
"cv06" on, /* `m` smaller middle apex (on!) */
"cv07" on, /* `W` smaller middle apex (on!) */
"cv08" off, /* `K Ж` straight without horizontal joint */
"cv09" on, /* `f` slab serifs (on!!) */
"cv10" on, /* `r` slab serifs (on!!) */
"cv11" on, /* `y λ` rounded tails (on!) */
"cv12" on, /* `u` spur (on!) */
"cv14" on, /* `¢ $` broken strikes (on?) */
"cv15" off, /* `&` like 'ET' */
"cv17" off, /* `f` curved */
"cv18" off, /* `2,6,9 curved diagonals */
"cv19" off, /* `8` symmetrical halves */
"cv20" off, /* `5` rounded bow */
"cv99" off, /* `С с` (cyrillic es) inverted‽‽ */
"liga" off, /* Sadly, not. */
"ss00" off !important; /* // just a terminating bogus without comma. */
I've put it into [1] along with some rules that makes it slightly easier to my eyes.
[1] https://userstyles.world/style/17888/owickstrom-github-iothe...
calt – Contains all ligatures. Substitution for : between digits.
ss19 – Adds gaps in ≠ ≠= == ≡≡ ligatures.
https://github.com/jantimon/text-box-trim-examples
You can see that even on this website, if you click "Debug Mode" (top right) and notice that later in the page, the headings and body copy begin to drift out of vertical alignment (against the background grid).
Honestly I'm surprised that it wasn't addressed long ago, seems like such a foundational issue for rendering text.
See more here: https://tonsky.me/blog/centering/
But so much time is being wasted on developers fine tuning magic numbers that the browsers are extending CSS to automatically fix the font developer's mistakes.
I made a similar thing where I take semantic HTML and render it as old RFC documents: https://vladde.net/blog/rfc-css/ (not as readable though IMO)
Nice work. Many very readable examples for others to draw on.
Websites have definitely gotten over-complicated and quite annoying. But this retro “look like a terminal” style seems like the wrong direction.
I like fixed width fonts in a terminal where it is very likely that I’ll have to interact with columns of text as a thing.
For reading, I mean, LaTeX was invented a million years ago, and can produce nicely formatted text. That should be the target IMO. If you want to copy something retro, copy an old magazine, they were nicely designed.
But I mean, I’ll take this over a program trying to run in my browser, lol.
The font is nice and I like the general concept, I have always liked monospace.
I built this page 'cause I like to use Emacs' EWW and Lynx from
terminal windows sometimes. It's sort of thematically related:
https://ohmeadhbh.github.io/bobcat/
Greycoder.com had the same idea at around the same time:
https://greycoder.com/a-list-of-text-only-new-sites/
And this is the typeface I use for my xterms:
https://github.com/lalo/VT220-mod-font
Monospace is awesome. I love what Oskar has done here.btw, was reading the CSS, I smiled. Love it. :-)
A way around this would be to split the font into multiple subsets based on unicode-range, like how Google Fonts do it: https://fonts.googleapis.com/css2?family=Open+Sans&display=s...
Sadly, I never quite figured out how to do it for arbitrary fonts easily, so for example I still serve comparatively large PT Sans, PT Serif and PT Mono fonts just because I like how they look. Maybe some day I’ll figure it out and will be able to automate converting all of the fonts I want.
Here’s something silly: you could probably put GNU Unifont on some page, the OpenType version of which is like 5 MB alone: https://unifoundry.com/unifont/
All that said, the JetBrains Mono font is a pleasure to look at on the site, as long as I’m not on a limited data cap.
> Maybe we’re just brainwashed from spending years in terminals?
Made me go ... Ugh...
Yes, I very much think so. To be fair, they do a fairly good job with the monospaced font they are using on this website, which is fairly legible. They also seem to actually have put thought into it, other than just doing monospaced fonts for aesthetics.
But, if your main content is semi long form text, then a monospaced font is simply not a good choice. Certainly not when the majority of people who use it on their blog don't give it nearly as much thought and attention as the author of this website.
I know many people on HN don't see it as an issue, certainly not people responding in this thread. However, there are decades worth of research into typography and typesetting on displays that makes it clear that a sans serif font (or even a serif font on modern displays) works better for readability. ¯\_(ツ)_/¯
Not sure what you mean by that.
Also, just because you spend a lot of time reading information formatted with monospaced fonts doesn't mean they are the best way for you to receive that information.
Part of it is preference, sort of. A specific crowd of people, many of who visit HN, are used to looking at monospaced fonts. So, they have effectively been trained to be able to deal with it more.
That still doesn't mean that, even for them, the text done with best practices wouldn't be easier to read.
Finally, as you might have noticed I also explicitly mentioned writing for a broader audience. Because people that are not working with code, terminals, etc all are not used to monospaced fonts.
But I disagree with the claim that monospaced fonts are easier to read, especially for longer texts and writings. The monotone rhythm will tire the eye, eventually.
Side note: the CSS “ch” unit can be handy to build monospaced layouts.
Monospaced fonts are harder to read in long form.
Using box-drawing characters when you have a web browser seems silly. I’d rather have minimalistic design with proper canvas, CSS, etc. You’re already using rounded borders, anyway.
My favorite font is Terminus for my code and whatever the New York Times Magazine font is for reading.
But when it comes to get the message across....Papirus.
Specifically, I want a monospaced site to display in the monospace font I choose for my browser. Because that's what I like reading.