I use the Poly variant by default, only disabling it in places where the monospacedness matters for layout purposes, e.g. the terminal recording in this article (because of Vim), and Rust compiler output in some of my other articles. The Poly variant does things like make i, l and space a little narrower, and m a little wider, which makes casual reading more comfortable than a strict monospaced font.
I do this because I believe that monospacedness is substantially overrated in most places, and that most things actually look better not strictly monospaced. I contemplated not even using a monospace-style font at all but decided that was probably going too far for most people. (And as a Vim user I necessarily work in a monospaced text editor; but if it weren’t for that, I’d probably go full proportional.)
So I’m curious if you have further feedback on this matter and why you find fault with what I’m doing. It may influence what I do.
I think one of the best reasons to use a monospaced typeface is that it is a fairly strong and accurate signifier of code. Of course, in this case you have special highlighting for it that makes it less useful, but in general I think that it really helps. (Plus there are a couple of other, minor benefits probably not worth listing here.)
As mentioned elsewhere I've been using proportional for code and it's very nice but for a small drawback. I'd say give it a try for a couple of days and see.
To you and anyone else with this opinion: try disabling the `code { font-feature-settings: "ss01" 1, "ss02"; }` rule in the CSS, which will disable the Poly variant, and let me know how it feels.
It seems possible to me that it’s actually the use of a true serif monospace font (>95% of monospace fonts used these days are sans-serif, and >95% of the remainder are slab serif) that’s throwing you off, more than the strict monospacedness of it, and I’d like to try that hypothesis out.
(In early development of the visual style, I used only the font with no spacing or colour hints, but I found the monospace Triplicate too similar to the serif Equity, so that it was sometimes not quite clear enough that it was code; that was the reason why I put the background colour on inline code rather than only on code blocks, even though that wouldn’t be done in a printed manuscript, which is a style I am loosely imitating in part.)
Disabling `code { font-feature-settings: "ss01" 1, "ss02"; }` made a marginal improvement for me but it was only marginal. The bigger issue I had was the type-face was too large.
Ultimately you're never going to win a discussion about type-faces because they're entirely personal preference. For example I find most proportional fonts to be too narrow and harder to read so much prefer the typically wider glyphs of monospaced type-faces. To the extent that the font I used on one of my blogs was rounder letters. I then had complaints that others found it "unreadable" and preferred something narrower.
I'm sure there will always be a sweet spot where more than average number of readers will be content however the web would be a little duller if everyone converged on that same type-face. So I'm willing to take a marginal hit on readability (and let's be honest, the different is almost always only marginal) for the sake of websites having their own personalities. The alternative if people can just toggle Reader View in Firefox (or whatever the equivalent is in other browsers)
I object to this whole thread as bikeshedding, however I happen to use proportional fonts for code (lucide sans unicode in windows) but just yesterday reverted back to a proportional font (lucida console).
While I much, much prefer proportional it's simply that indented stuff after text didn't line up properly in it eg.
stuff = 23
more stuff = 99
x = 41
(edit: sorry HN is messing up the indenting even further, but you know what I'm getting at)
Also my magit popup buffer is all ziggy-zaggy instead of properly column'ed. I can live with that. Edit - and git log which relies on fixed-width to show properly gets all bollixed.
In your case I can't see your code suffering at all from these problems, so I'm fine with it.
The niceness of proportionals may be enough for me to go back to it. I don't know yet.
Interesting. I’ll give the thought time to settle and probably disable Poly for all code blocks tomorrow, leaving it on only for inline code. (That’s what I did initially in the design, but then I decided to make normal code blocks Poly as well because I preferred it so, and why not? —But it seems to be disconcerting people.)
Yet one of the things I really like about Poly is how it decreases width. Disabling Poly would slightly harm layout on https://chrismorgan.info/blog/rust-fizzbuzz/ where I have code side-by-side, increasing the width required for the full layout without wrapping from ~1500px to 1600px. Ah well. It’s not critical, just makes me a little bit sad. (Admittedly I could get much of that back with `tab-size: 3;` instead of `tab-size: 4`, but that would doubtless make people baulk too. And I’m not going `tab-size: 2` except on small displays.)
I'd gently suggest that, while the side-by-side code is a strong with the early for loops, it's not adding much as much value for the longer snippet with the Display impl.
I use Triplicate, Concourse and Equity extensively. Equity, there are surprisingly few fonts like it in its organic feel and faithfulness to the old art of printing. (This doesn’t convey as much as I’d like, but I lack the terms of art to describe what I mean properly.) Triplicate, well, it’s the only good true serif monospace that I know of, and I like that. Each font fills a niche that I very much appreciate. I reckon they were worth buying on their own merits, but it was also then a way of supporting Matthew Butterick’s project https://practicaltypography.com/ which I strongly approve of as a project.
