>> The solution to this problem: “uniwidth” typefaces, sometimes also called “equal-width”, “duplexed” or “multiplexed” typefaces. And no, I am not talking about monospaced fonts here.
I'm not into web design but I think the core problem here is lack of accepted terminology and even awareness that this type of font is a thing.
The article certainly brings awareness to something I didn't know is a thing but seems very useful.
My mind wants to say "weight invariant" or "style invariant" but those suggest the thing doesnt look any different rather than just the size not changing with other characteristics.
It's probably obvious that I don't like "uniwidth", but at the moment I can't think of anything better that isn't super wordy, like "font with style invariant width".
> I'm not into web design but I think the core problem here is lack of accepted terminology and even awareness that this type of font is a thing.
It seems useful to name the property where character widths are consistent along their weight axis, but another case in point to support the sibling comment: I see only one other significant use of "uniwidth"[1], from 2015.
I also find "uniwidth" a poor and confusing name for this property, and "duplexed" and "multiplexed" even worse.
If I had to suggest a better alternative, I think something like "width-invariant" or "width-invariant proportional" would be clearer.
As someone who does type design, "duplexed" is the term I've seen used most often. It is usually used when talking about tabular numerals, which are monospaced and duplexed (sharing the same advance width for glyphs across all weights).
Edit: Like most font terminology, I think it has historical roots predating digital type, and refers to the way styles or weights might sit above one another on the matrices.
‘Duplexed’ comes from Linotype machines that used a pair of fonts, normally roman and italic, on a set of matrices. For mechanical reasons the two versions of each character had to be the same width.
If you're going to use the term 'invariant' then 'width-invariant' is a bit unfortunate as that seems to imply it is invariant w.r.t. width, rather than that the width itself is invariant w.r.t. something else.
The most 'correct' version would be 'font with weight-invariant width', but that's a bit long.
Case in point: one of the fonts mentioned, recursive, has been on HN before (with 108 comments), but I only found one comment that explicitly talks about this property, and it doesn't do so by name. https://news.ycombinator.com/item?id=23934409
Yep I initially thought "uniwidth" is synonymous with "monospaced" fonts.
But these uniwidth fonts can have Sans and Mono variants like Recursive[0], so methinks these could've been just called what they are: "no-reflow" fonts? lol
Somewhat interestingly, there is a great deal of inconsistency in naming in the type design world — both in marketing features like this, but also down to terminology for specific parts of letters. I agree that it would be very useful, but for whatever reason it never seems forthcoming. My assumption has always been that type design is a fairly distributed discipline (at least amongst latin-alphabet-using countries), but remains niche, so there’s more or less only regional terminology without much consistency. (This is purely observational, so take from this what you will)
Fonts designed in this manner have been around for awhile, so it’s not really a new concept, except in its application to every glyph in a type family. The term I’ve used with type and other designers is actually “tabular,” which contrasts with “proportional.” Look up tabular vs proportional numerals for a topic that’s been around since printing presses ruled publishing.
Tabular numerals are actually more like monospace than uniwidth[-as-defined-here]; it's a font where all characters have the same width... as long as those characters are numerals. Variations like "weight-tabular" or "numerically-tabular" might work, although it's less obvious which properties "tabular" is holding constant (namely width; technically also height but noone varies that anyway).
Agreed, though I maintain that it's in general unclear exactly which properties the advance width is constant with respect to. (For tabular numerals, is-digit-zero-versus-one clearly is, but what about digit-versus-question-mark when writing "27'3?? items" to indicate three significant figures? What about "+" and "-", which should have the same width as each other, despite not being numerals at all? Full monospacing solves this, but that's often a stronger constraint that you actually need.)
Also, nominally monospace fonts often end up having character-dependant width anyway (ranging from blatant bugs like substiting fallback characters without forcing them to the correct size, to completely legitimate-ish variations like CJK ideographs with integer multiples of the normal character width). So, I'd still say tabular numerals are more like a weaker form of monospace than a stronger form of uniwidth - constant width across styles may or may not be relevant, but if it is, it's table stakes (no pun intended).
Yep it's totally up to the type designer which extra glyphs are supported alongside tabular numerals. Usually period, comma, plus, minus, equals, dollar (and other currencies), space, but I've never thought to include a question mark in the set.
> also called non-proportional font, is a font whose letters and characters each occupy the same amount of horizontal space
instead, it preserves the width if you apply a weight like BOLD:
> Uniwidth typefaces, on the other hand, are proportionally-spaced typefaces, but every character occupies the same space across different cuts or weights.
This allows visual cues other than color in interactive text such as the :hover CSS pseudo-class.
"Monospace typefaces give each letter the same width"
"Uniwidth typefaces preserve the width across different weights ( Bold, etc. ) although each letter may not necessarily be the same width."
I feel like the above short summary should have been more easily visible in the article. From skimming the article I couldn't figure out exactly what Uniwidth typefaces were.
Ahh, very satisfying to learn the name of this property.
It’s especially important in data tables when coupled with tabular numbers (essentially mono spaced numbers) so you can e.g. bold a cell without having the thousands or decimal separators get out of alignment in a column of numbers. Spreadsheet programs use fonts with this property.
Fonts in general usually keep their numerals and certain punctuation characteres all of equal width, and of equal width between regular and bold (even when their letters get wider in bold).
It's not really something special spreadsheet programs do or select for. It's just how basically all workhouse body typefaces operate, like Helvetica or Times New Roman or Calibri, precisely for the reason you list.
True. Verdana is a weird font in a lot of ways -- it was designed for low-DPI screens in the 1990's, mainly as an interface font for Windows. It was never intended for print at all, and so doesn't follow some standard typographical conventions (such as bolded numerals being the same width).
Which is why when IKEA chose it as their main branding font (in their print catalog, no less!) to replace Futura, there was such an outrage among graphic designers, as it was such a terrible choice. (IKEA no longer uses Verdana anymore though.)
Also called Lining Figures, this property is a lot more common than “duplexed” alphabetical glyphs — even if they are not the default, most text fonts now support them as an opentype feature.
My understanding is that the term “lining” refers to numbers with the same height, (which is also common and appreciated in data tables!) and that “tabular” refers to numbers with the same width, so not quite the same thing: https://creativepro.com/typetalk-know-your-figures/
Conceptually, this is certainly intriguing. Unfortunately, I don't see it as being of much practical use for two reasons.
First, with internationalization, your carefully selected label widths will be destroyed anyways. Because translated strings frequently take up more space, you should always be designing your interfaces with plenty of extra room/flexibility anyways.
And second, with the idea of bolding on hover -- that's really not a great UI pattern to begin with.
From a fundamental design point, bolder strokes require more separation between them, which is why fonts are generally slightly wider as they go bolder. These "uniwidth" typefaces just look uncomfortably squeezed. It's aesthetically not a great solution.
Rather than bold-on-hover, better hover effects include lightening/darkening, underlining, outlining, highlighting, inverting, etc. But if for some reason you're absolutely determined to bold on hover, then just use some layout magic to accomodate expanding the width of the label (likely centered rather than left-aligned, if in a horizontal list) without disturbing items around it.
I will note, however, that fonts often ensure their numerals and certain punctuation remain the same width -- Times New Roman's letters change width if bolded, but its numerals do not -- as it's common to have certain rows in a financial report be bold, and you don't want the numerals to be misaligned with non-bold lines. So numeric tabular data seems like the main use case here, really, which fonts already help take care of. (If you have lots of tabular data with letters and need bold, then you should just be using a monospaced font.)
Your internationalization issue makes no sense at all to me: this isn't about making everything the same width, as these are explicitly proportional fonts... the mechanism is merely that if you have an italic or bold version of the font that you won't get weird "popping" or layout changes.
You are also slamming hard the idea that this would ever be interesting, and yet almost every single communication app I've ever used has chosen to use bold to mean "unread", and it definitely makes sense that if you click on something to read it it shouldn't pop or cause a layout change.
Your first argument applies to large apps that need to be localised to many languages. It's a non-issue when you are creating say a web for a local small business or an app with just a few views.
> Duplexing. In type, duplexing means matching the widths between styles so that each character occupies the same space on the page. This way, you can easily change the weight and style without affecting your layout. In Concourse, weights 2, 3, 4, and 6 are duplexed to each other. (For this reason, the three lighter weights all use weight 6 as their bold style by default.) Every italic is also duplexed to its roman, including weights 7 and 8.
So yeah, all normal use is duplexed, but it has a couple of extra-bold weights that don’t fit that way.
This also draws attention to the other area you may want to think about this with: italics. Definitely depends on the style; broadly speaking, serifs won’t want to duplex their italics (they’ll most commonly be narrower), but sans-serifs might.
I started reading thinking that uniwidth is the new politically-correct term for monospace :)
But, I agree with the author - it's a great concept to be emphasized especially for tabular displays! Does it work for other languages, e.g. Indian languages with complex ligatures? Also, the following is a major pain point in the correct display of Indian languages:
I love the concept of uniwidth typefaces, but the problem stands that almost every single uniwidth font looks fundamentally _differently_ when you bold them or not.
The aspect of bolding in normal fonts makes them easier to see, and increases the spacing to accommodate, but nearly every uniwidth bold font fundamentally changes the font to shift them to a new font that is marginally based on the non-bold.
I'm not saying I entirely dislike them, or that there aren't good uniwidth fonts out there, but it's just that in almost all cases the difference in the same font set is fundamentally different.
That may very well be a function of the design choices made by the authors of the uniwidth fonts created to date, which is arguably a limited sample size at the moment.
While this might be useful in certain cases, don't get your hopes up: i18n will break your carefully laid out equal width layout. E.g. many german terms will be longer than the english equivalent, causing all the same problems, just even more annoying because you as an english-speaking developer won't notice until it hits your foreign users.
Give up on pixel-perfect design or give up on i18n. You cannot have both (or rather you cannot afford a redesign for each new translation).
I think you're missing the point. i18n is just a change in the static content, which is mentioned in the article, but is pretty quickly dismissed:
> While this feature allows for some creative layering in static typesetting, it is decidedly spectacular for interface design, where things tend to quickly go awry with only small changes. As an example, changing the weight of a single menu item on hover usually results in an erratic twitching dance of the whole menu as it tries to adjust for the change.
> this feature is nothing but a nice gimmick in static typesetting,
The point is that when the font attributes change dynamically when using the interface; like hovering over a button makes the text bold. If that dynamic during-interaction change changes the size, it might make everything else move around too, which would be bad.
The problem being addressed isn't so much being able to get the page to look just so, but being able to make it not jitter around while you interact with it.
Whether it'll work or not for the various non-Latin scripts will depend what fallback fonts the browser happens to pick, so people's results will vary.
Your jsfiddle also fails even for English in most browsers, because you didn't load both regular and bold weights of Recursive. As a result, you get a browser-generated synthetic bold effect, which varies between browsers and in most cases (but not Chrome, IIRC) will alter the width.
(To fix that aspect, you need something like "family=Recursive:wght@400;700" in your Google Fonts link.)
In this case, the problem is that the Recursive font doesn't actually contain the Arabic and Japanese characters, so the browser is falling back to another font. If you use a uniwidth font that actually contains all the characters, this should work.
For it to have worked each pair of lines should be the same width. They are not. Tested on MacOS 11.1 Safari, Firefox, Chrome and Windows 10, Firefox, Chrome. All failed.
It becomes _even more important_ for i18n. When you’ve worked out your maximum character width for each element across all languages you support, every pixel counts. Knowing that applying bold is not going to cause a reflow in one of the languages you’re not currently working with is a huge boon.
This is true for static layouts. However I think the compelling use case is when the font weight changes dynamically such as on hover or focus. In this case it can be useful to avoid having the layout shift (especially on hover where the shift risks moving the hover target and creating an unwinnable game of cat and mouse).
I have often felt the pain of how elements "run away" from under you when you hover over them, due to glyph width changes or other visual effects by an overly clever website designer.
This seems like it might be useful for people who are doing DTP type work and don't want their entire document to reflow itself because they changed the font weight of one word.
(I try to avoid cheap low-brow dismissals here, I know it's lame, but the word "kern" isn't on the page, nor in these comments as I write this, so somebody was going to say it first, and today I guess it had to be me.)
Seriously though, it seems to me like your thin text is too far apart and the thick text too close, no?
Of course. This is an obvious tradeoff. For just this reason, I don’t think these typefaces are ideal for regular text, but can be an improvement for labels, buttons, numbers in tables, etc.
Alternatively, choose UI design ideas that don't involve changing the font weight on hover. What's wrong with changing the colour and/or background instead? Or (for an element like a button) give the element a fixed width that is sufficient for either weight of the text.
Sometimes, if a design idea turns out to cause problems, maybe it's time to reconsider the design.
This is a pretty weak justification for what seems like it'd usually be a design gimmick.
It's perfectly possible for a colour change to be accessible for the colour blind, if you do more than just modify the hue. (Extreme case: change white-on-black to black-on-white. Or more generally, swapping foreground and background colours would usually be adequate, unless there's a serious lack of contrast in the first place.)
Or add an underline, or a border around the element. Point is, there are safer options than font-weight; changing weight is pretty fragile unless you tightly control other aspects of the design/content.
No, as the article explains at length. In monospace fonts every character occupies the same line space. In uniwidth fonts, the characters occupy the same space across different weights, e.g. a bold "w" occupies the same space as a regular "w", but they may differ in width from each other.
Sure there is, it's a different thing. Many monospaced fonts are also uniwidth, sure. The article is promoting fonts that are non-monospace but are uniwidth. It would be wrong to apply the term "monospace" to these fonts, so a second term certainly is needed.
All (good) monospaced fonts are uniwidth, not all uniwidth fonts are monospaced.
Monospaced is important if you want multiple sequences of the same length to line up, uniwidth is less restrictive of the font (because "l" and "w" can be different widths) but allows you to bold without changing the visual length.
It really is right there in the article which you don't seem to have read in full and explained fairly indepth what the author means by uniwidth and why it's important to him and possibly to other UX designers.
You have misunderstood the important difference between uniwidth fonts and monospaced fonts. Uniwidth fonts are proportionally spaced; monospaced fonts are not (by definition).
The distinction is made very early in the article:
> Uniwidth typefaces, on the other hand, are proportionally-spaced typefaces, but every character occupies the same space across different cuts or weights.
I'm not into web design but I think the core problem here is lack of accepted terminology and even awareness that this type of font is a thing.
The article certainly brings awareness to something I didn't know is a thing but seems very useful.
My mind wants to say "weight invariant" or "style invariant" but those suggest the thing doesnt look any different rather than just the size not changing with other characteristics.
It's probably obvious that I don't like "uniwidth", but at the moment I can't think of anything better that isn't super wordy, like "font with style invariant width".