Hacker News new | ask | show | jobs
by duaoebg 2222 days ago
I second the mono space for code suggestion. I guess my brain is wired to see when characters are offset slightly as wrong. It’s a bit unsettling.
1 comments

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.

Further edit: thanks for the article!

In monospace that typeface looks glorious. I'd recommend continuing to use proportional for inline keywords, though.
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.