81–90 of 206 posts
No hinting apparently, so only for hi-DPI.
There is no point in cranking out yet another code font that doesn't have hinting. PragmataPro and Berkeley Mono are such well loved fonts not because of their aesthetic quality (code fonts are (proudly) ugly), but because of how well their hinting has been done.
If I want an unhinted, but well performing, font... there is Iosevka. Which I use.
Earlier quoted context omitted.
Fortunately for you the ligatures are optional and have no impact on the underlying text. To be "left alone" you have to do exactly nothing.
> To be "left alone" you have to do exactly nothing. Unfortunately that's not true. The problem shows itself when looking at codeblocks that developers share (in docs, blogs, videos, etc...) Ligatures become a readability problem.
How would you configure a text editor or terminal to use different fonts based on syntax (e.g. neon for code, argon for comments)?
Using this approach, you can use up to 4 different fonts: One for normal text, one for italic, one for bold, and one for bold italic. And the font for each group doesn't necessarily need to be that style, e.g. you can use a non-bold version for the `bold` font, etc.
I like everything about this! Font families seem like an incredible idea that I'm surprised nobody's done before, variable fonts are new to me and super interesting, textural healing seems like a huge step forward, and damn if that isn't one of the smoothest sites I've ever played with. Nice work!
> Font families seem like an incredible idea that I'm surprised nobody's done before Oh this has been done for decades . Metafont (by the inimitable Don Knuth) let you describe glyphs as toolpaths in code. You could have as many parameters as you wanted; I've seen examples where a sans-serif is smoothly swept into a serif. Metafont never got adopted as much as I would have hoped; the lack of a graphical editor and so…
This beautiful feature is created by the GitHub team and is only available on VS Code, strengthening its lead over the other editors.
This fact has led me to look more closely at Commit Mono, suggested by nvartolomei in his comment (this article). I love the texture healing idea, and that font looks to be more open and easier to use in other environments.
It's a shame that on VS Code at least (I'm not sure if this applies in other contexts), the "textual healing" feature goes hand-in-hand with ligatures. There is no way to enable textual healing if you prefer not to use programming ligatures.
From https://github.com/githubnext/monaspace?tab=readme-ov-file#v... > If you want coding ligatures but do not want texture healing, you can elide the calt setting:
`overflow: scroll` is almost never (p>0.999) the right thing, and users that don’t use overlay scrollbars are suffering because of the poor choice of name, getting a forced scrollbar when one is almost never appropriate. (This includes almost all Windows for now, I believe; and some Linux, probably no longer most since GNOME is bent on ruining everyone’s life; and some macOS.)
—⁂—
When is `overflow: scroll` legitimate?
One obsolete case is preventing document scrolling when a modal is open, without triggering reflow due to the scrollbar disappearing, but I say the side-effects are still worse than the problem (the document scrollbar is nonsensical while the modal is open), so you should let it be (why was scrolling the document under the modal such a problem anyway?), or prevent scrolling by means other than scrollbar manipulation, by capturing it in the modal backdrop.
Another obsolete case is avoiding a bit of layout shift when switching between pages if some fit in the viewport an others don’t; but honestly it’s so long since I’ve seen a site where any pages fit in the viewport… and more to the point, this is better handled with `scrollbar-gutter` (not supported by Safari; you could use @supports to fall back to `overflow: scroll`, but the importance and number of affected users—since Safari is normally overlay scrollbars—are so tiny I don’t think it’s worth it).
The only arguably legitimate case I can think of is on spreadsheets/data grid components, where you can reasonably prefer to display a noop scrollbars rather than just reserving the space for them.
OK, and one other: code to find scrollbar dimensions for various layout purpose normally uses `overflow: scroll` on a temporary element and this is legit, even though you could do it other, mildly more complex ways; but it also makes assumptions about scrollbars always being the same size, and there’s honestly no reason why they should be, and `scrollbar-width` has shown a distinct appetite for using thinner scrollbars in some places and a browser could reasonably vary its default scrollbar width based on the dimensions. And scrollbar-dimension-finding isn’t particularly common, and the problems it’s used to solve are mostly better handled in other ways; now if only viewport units weren’t broken by design in the presence of document scrollbars…
I’ve contemplated campaigning for explicit deprecation of `overflow: scroll` and getting warnings shown in dev tools if you use them, because I’ve seen it misused so many times in the last decade, where people actually meant `overflow: auto`, and other than scrollbar-dimension-finding doubt I’ve seen even a single legitimate and reasonable use in that time.
Earlier quoted context omitted.
> To be "left alone" you have to do exactly nothing. Unfortunately that's not true. The problem shows itself when looking at codeblocks that developers share (in docs, blogs, videos, etc...) Ligatures become a readability problem.
If it bugs you that match, usercss?
I'm always really confused about how dotted zeroes became the norm for these fonts. I always confuse them with eights and vastly prefer slashed zeroes. Would love to try this if it had such a variant.