The Monospace Web(owickstrom.github.io) |
The Monospace Web(owickstrom.github.io) |
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.
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?
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.
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).
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.
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.
[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.
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...
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)
/*
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.
I think that's a great idea. You can go a long way with just Unicode these days: https://gwern.net/utext
All you need HTML/CSS for in an ordinary Gemini/gopher/Markdown-style document is clickable hyperlinks, really, and you can hack that by alternating a bit of HTML or by client-side convention.
So most of the Japanese amateur internet? :V
(CJK fonts are mostly monospace.)
I found this https://ux.stackexchange.com/questions/48753/does-the-use-of...
- > In Universal Principles of Design, the entry on legibility states: Proportionally spaced typefaces are preferred over monospaced.
- It's unclear if that book provides further evidence to this statement
- > One famous research on this is Beldie I. P., Pastoor S. & Schwarz E, 1983, “Fixed versus variable letter width for televised text”, Human Factors, 25, pp.273-277, where part of the results include: The reading time (Task 1) with the variable-matrix character design was 69.1 s on the average, and the mean reading time with the fixed-matrix character set was 73.3 s, t (8) = 2.76, p < 0.02. The difference is 4.2 s or 6.1% (related to fixed-matrix characters).
- I couldn't find a pdf of that one in particular. The difference seems small
- https://www.tandfonline.com/doi/abs/10.1080/0144929021014673...
- > Comic Sans MS, Arial and Times New Roman typefaces, regardless of size, were found to be more readable (as measured by a reading efficiency score) than Courier New.
- small sample size 27 children. also the children preferred comic sans... we could pick a cooler monospace font than courier new
- https://link.springer.com/article/10.1007/s10209-015-0438-8
- > It was found that larger text and larger character spacings lead the participants with and without dyslexia to read significantly faster
- unclear if those were monospaced
- https://www.researchgate.net/publication/20925173_Reading_wi...
> We compared the effects of fixed and variable (proportional) spacing on reading speeds and found variable pitch to yield better performance at medium and large character sizes and fixed pitch to be superior for character sizes approaching the acuity limit.
Or maybe more resources here: https://fonts.google.com/knowledge/readability_and_accessibi...
People tend to apply results from proportional font studies to monospace fonts. I guess monospace text isn't popular enough to get its own studies.
We need more readability A/B tests in general.
- those fonts will have different sizes (not guaranteed to be metrically compatible), which would make working with UI harder
- sometimes the built in fonts look pretty unpleasant (Courier New, anyone?)
- it will look different on every OS, which in most cases will also complicate testing and hurt branding (in actual projects)
Instead, nobody cares and the only options we have are to either use the crappy web safe fonts, or waste bandwidth to make websites look better. Luckily, if you prefer the former approach, then you can untick "Allow pages to choose their own fonts, instead of your selections above" in Firefox options or the equivalent in other browsers.
https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
Or maybe it was just a plain ol' textfile, I forget.
If you have something to say, I have nothing against improving its typography.
If not, I'd argue for concentrating on spending effort finding, not a better typography, but better words.
:: :: ::
> Not sure what you mean by that.
Older research papers were often written with typewriters, leaving blank spots on the page for formulae, which were then (to a greater or lesser degree) put in in a second pass, with methods ranging from straight freehand to using drafting tools for lettering them.
eg (1951) https://www.rand.org/content/dam/rand/pubs/research_memorand... p13
Sure, but this being the web and the font choice literally being one line of CSS it is not that hard to make things slightly better for everyone involved.
Even more so when a lot of the blogs I have in mind also try to appeal to a slightly broader audience than just the nerds used to monospaced fonts.
> Older research papers were often written with typewriters, leaving blank spots on the page for formulae,
Well, if you read them on paper it is a slightly different story. That is one of the main issues, fonts work differently on displays than on paper.
If you mean that you read these scanned papers, then I'd say that your argument mostly boils down to you being used to it by now. People can get used to a lot of things, to the point that they think they prefer it out of habit. That doesn't mean that they are actually better and can't be made better for other people starting out who are not used to these things.
For instance, in this very convo what matters is that we're talking past each other, and I think that'd likely happen regardless of whether our comments were in fixed or proportional fonts, regardless of what other typographical choices might be made.
Where monospace was pragmatic for the typewriter era because of the limitations of the technology, proportional is the pragmatic _and default_ styling of the web.
Choosing monospace today for prose is an opinionated, and in my opinion suboptimal, choice.
Sure, there are better typographical choices than monospace, but even bothering with that decision is like optimising a 2*x to an x<<1 in code that's hitting disk anyway.
(on the flip side: it doesn't matter how easy it is to read a sequence of words, or how beautiful they may be, if they don't communicate anything; the code analogy is that it doesn't matter how much faster a buggy change runs)
Does that make sense?
https://news.ycombinator.com/item?id=28651093 (this very faq)
https://news.ycombinator.com/item?id=40773880 (jart's commit)
https://news.ycombinator.com/item?id=40605970 (tom7's gnujpl)
and bonus: recently i've been enjoying http://arlyle.sdf.org/
(unfortunately, links do not work in preformatted text on hn)
Thanks to AI, now you can.[1]
[1] https://suno.com/song/22f52bca-7119-4aac-8f0a-5daf9afa509d
(Also an amusing waste of time. Here's "a religious folk song in the format of a Cisco configuration file": https://suno.com/song/536fe16f-079c-4cce-921c-c2518f6dedb6 )
Don't worry; I pasted your words
into vi just to experience their
fully justified bricktext glory.
Incredible catharsis. Love it.
That doesn't change the fact that in environments where there is control over all that monospaced fonts rarely are the best choice for large bodies of text.