The css tag does not adequately describe the extent of the problem. Admittedly, CSS’ flaws compound it, but some of the examples Tonsky furnishes are native apps that come bundled with macOS. Most of what he discusses relates to fonts, font metrics, font design, and the drawbacks of using icon fonts in user interfaces.
Which is wild since for the web SVG sprites have been suggested since around 2014. Seems a lot of folks learn just enough front-end at one point in their career to solve a problem, then never read the patch notes for updates to the meta (which isn’t to say follow all trends, especially when it comes to the topic of ‘frameworks’, but other things are basic building blocks worth refreshing).
Indeed, I don‘t see how anyone who’s bothered to do a quick web search in would come to the conclusion that they should install an icon font in a web app in 2024. As I recall, the argument for icon fonts in web apps some 5–10 years ago was that it was easier to bundle with webpack. Since then, webpack and various other bundlers have supported importing SVG from JavaScript, or at least plugins/extensions that do. This has carried over as an implicit expecation of metaframeworks as well. When used with static and server rendered components, the code looks the same, but the sprite remains on the server rather than being bundled as a string in the client-side JS app, which increases load and parse times.
However, Tonsky is claiming the abuse of icon fonts goes beyond the web—that it extends to native apps. What surprises me most is his claim that the Calculator and Quicktime apps that come bundled with macOS switched to icon fonts in 10.15. Does anyone know if he’s referring to SF Symbols? So far as I can tell (and I have not gone any further than skimming the docs), SF Symbols is not a font but rather a vector-based icon library designed to go with the San Francisco system font. I have not found any evidence that it is a font itself, nor that Apple uses icon fonts. That’s not to say that SF Symbols or its implementation in these apps are perfect, but the more I re-read Tonsky’s article, the more I doubt his diagnosis that icon fonts are really as pervasive as he says, at least in native apps.
It’s easy to make jokes about this. But have you ever tried to design a layouting engine? It’s not as easy as it sounds. Some elements are sized or positioned depending on their contents. Other elements are sized or positioned based on the parent element. There is a huge number of dependencies between all the different elements and you, the layouting engine designer, have to make it all work out. In particular, you should avoid cyclic dependencies. And somehow communicate this to the person who uses your toolkit to create a GUI. Then there are issues where elements jitter back and forth because there is a bistable resolution to the constraints, such that the elements resize themselves and each other endlessly… And so on. It’s very easy to center one element in a simple and known context. It’s very hard to position all the elements in the general case.
I mean, okay, layout algorithms are complicated. (Although there is literally no excuse for “elements jitter back and forth”). But I find this attitude a bit pessimistic: you’re effectively saying that OP should temper their expectations because centering things really is a very hard problem, even relative to the ability of companies like Apple and Google.
That doesn’t quite ring true to me. Web browsers solve lots of hard problems. They don’t seem to have any issue with adding newer, more complicated layout algorithms that don’t help much with this. Also for some of these examples layout engines aren’t even in the picture. It seems to me that we probably haven’t solved this decisively because (a) not enough people care, and (b) it’s a problem with lots of causes that all need to be solved before we see any improvement.
(Although there is literally no excuse for “elements jitter back and forth”)
You’d be surprised :-)
A classic case of this problem is websites that are just tall enough that a scroll bar may or may not appear - which in turn affects the actual page width. Various browsers have implemented various quirks to deal with this.
you’re effectively saying that OP should temper their expectations because centering things really is a very hard problem
I’m not. OP should not temper his expectations. If he can do it better, more power to him. I wish him and everyone else who works on such problems the best of luck and a lot of success. All I say is that it’s easy to joke about it, but very hard to fix across the board. You can center Latin characters? Good. Now do the centering algorithm for literally every character combination in Unicode. What these problems have in common is that one single defined case is very simple, trivial even, but the general case is nigh impossible.
Came here to say basically this. Everything has to position itself relative to something else, and so with a complex layout there’s a lot of non-local data floating around. It’s also very easy to make positioning decisions that appear to work properly until something else changes, so it’s hard to find bugs.
Life was much easier in 1992 when you just hardcoded everything to specific positions on a 320x200 pixel screen. :-P
Has anyone ever attempted a “mass-based” centering algorithm?
I.e., instead of relying on bounding boxes for anything, compute the center of mass of the relevant pixels (pixels in font glyphs, non-transparent pixels in an icon, etc.), and layout based on that.
I can see it being expensive, but it should fix a lot of these issues iiuc.
I’m worried that the mass centring would be worse. As a contrived example, imagine three buttons labelled
M
M.
M,
If you aligned the centre of mass of the pixels, the top of M would move slightly up for each consecutive button. I expect that users would find it more aesthetically pleasing if the tops of the three letters were aligned.
I’m not sure about worse, though I’m now convinced mass isn’t sufficient by itself.
To follow your example, what if the letters on the buttons were “M”, ‘i”, and “x”? Aligning by top would make those look even less centered than by mass. (Baseline wouldn’t be too bad, but then that’s not centering.)
Seems like for those examples, you would just apply horizontal centering, not vertical. To align them vertically, you’d just align their ascenders and descenders. Am I missing something?
The alignment procedure you described is the proper solution. The only thing you’re missing is an idea that you probably rejected as too obvious to be the point:
Centre of Mass centring can be a useful tool in the alignment toolbox, but it doesn’t work as the sole alignment method for all situations.
Pretty sure that would be terrible for text, but it seems like a good heuristic for glyphs. What I see is that the visual center of mass is sightly different from the center of pixel mass. The goal IMO would be for designers to design their logos such that the center of mass of the bounding box is where they want their visual center of mass be, rather than to have the bounding box be as small as possible. It would be even better if Images could have 2 bounding boxes, one specifying the canvas size and the other one for laying out, similarly to descenders in fonts.
I’m not sure that would look visually balanced. Eg a logo that’s mostly one shape with a bit sticking out. Or take font: the center of mass would probably be slightly higher than the middle of x height but lower than the middle of the cap height to baseline interval. And a section of all caps would be different than regular text next to it.
I’m not sure this will change your mind, but to clarify: I’m suggesting the center of mass of the largest meaningful level, not individual glyphs.
As for the logo you described, maybe we could downweight by the distance from the center of mass, to minimize the effect of little hanging bits (e.g., Q)
For my font comments, I also meant the largest meaningful level. I’m saying if you took a line of text and got the center of mass, I would guess the center of mass of the whole line would probably be slightly higher than the middle of x height but lower than the middle of the cap height to baseline interval. When I say a section of all caps next to a section of regular text, I mean like in the examples in the article, where you might have two buttons or spans near each other: they’re supposed to be at the same “height”, but separate enough that they wouldn’t be calculated together.
I still don’t think the logo would work, because if we took a Q and a flipped Q, unless we weight the parts that stick out at zero, they’d be oddly jiggled. Or even take a square, where the top-left 1/4 is filled, vs the bottom-left in a different logo.
Fonts are one of the biggest offenders. You can see poorly aligned text everywhere. Let me showcase. Apple can’t do it: …
That button’s text is vertically centered: the lowercase letters that make up most of the text are within a pixel of perfect centering. It happens that the caps stick out less far than the descenders, so the glyph bounding box isn’t perfect, but that’s not really what the eye pays attention to.
Consider also that it’s really important to have baseline alignment of text in a row of buttons, so vertical layout can’t consider the individual glyphs in an individual button title; it has to use only the font’s metrics.
Well yes, but I feel like the article in question is trying to make the point that text should be laid-out as-if it were cap-height high, not x-height. And that ascender and descender should be a symmetric margin around that height.
Using the cap height to vertically align text doesn’t make visual sense when the great majority of the letters are lowercase.
And ascender and descender heights are up to the type designer and are not usually symmetrical.
When you consider accent marks too, things get even more confusing.
It’s kind of cute that a bunch of coders are thinking about these sorts of layout issues, but trust me, there are visual designers who know a lot more about this than we do. I’m not saying some of those examples aren’t terrible, just not the ones from Apple.
ruined the QuickTime record button: [screenshot] Just look at it: [zoomed-in screenshot] Yes, it actually looks like this to this day.
Okay, the inner, red disk is off-center in the outer, white disk. I don’t think I would have noticed if not for the zoomed-in picture. When it’s not zoomed-in, the difference is tiny. I do not believe this tiny asymmetry would prevent anyone from being able to tell that this is a “Record” button. I find this person’s standards too high.
Please pay attention. Please care. Bad centering can ruin otherwise decent UI: [screenshot]
Okay, the form input field’s label is slightly misaligned with the input field, but it’s still clearly attached to that input field. I find this person’s uses of “ruin(ed)” for these slight misalignments unsympathetically hyperbolic.
I can read it, but it’s much further from perfect than the “ruined” examples I cited, and it might not be understandable to readers with some but not full understanding of English, whereas I have difficulty imagining someone who knows what a perfect “Record” button looks like being unable to recognize the slightly imperfect QuickTime one.
(I acknowledge that this is not exactly an answer to your question.)
My point is that “recognizability” is not the criterion of quality. You’re setting a very low bar, just as the OP is setting a very high bar. In practice, something can be completely recognizable and usable while presenting an appearance of very low quality.
I was super confused for a second thinking someone else was controlling my screen or something was accidentally brushing the trackpad. Turns out the blog is just animating these fake cursors (look for /** POINTERS */ in https://tonsky.me/script.js).
The css tag does not adequately describe the extent of the problem. Admittedly, CSS’ flaws compound it, but some of the examples Tonsky furnishes are native apps that come bundled with macOS. Most of what he discusses relates to fonts, font metrics, font design, and the drawbacks of using icon fonts in user interfaces.
Which is wild since for the web SVG sprites have been suggested since around 2014. Seems a lot of folks learn just enough front-end at one point in their career to solve a problem, then never read the patch notes for updates to the meta (which isn’t to say follow all trends, especially when it comes to the topic of ‘frameworks’, but other things are basic building blocks worth refreshing).
Indeed, I don‘t see how anyone who’s bothered to do a quick web search in would come to the conclusion that they should install an icon font in a web app in 2024. As I recall, the argument for icon fonts in web apps some 5–10 years ago was that it was easier to bundle with webpack. Since then, webpack and various other bundlers have supported importing SVG from JavaScript, or at least plugins/extensions that do. This has carried over as an implicit expecation of metaframeworks as well. When used with static and server rendered components, the code looks the same, but the sprite remains on the server rather than being bundled as a string in the client-side JS app, which increases load and parse times.
However, Tonsky is claiming the abuse of icon fonts goes beyond the web—that it extends to native apps. What surprises me most is his claim that the Calculator and Quicktime apps that come bundled with macOS switched to icon fonts in 10.15. Does anyone know if he’s referring to SF Symbols? So far as I can tell (and I have not gone any further than skimming the docs), SF Symbols is not a font but rather a vector-based icon library designed to go with the San Francisco system font. I have not found any evidence that it is a font itself, nor that Apple uses icon fonts. That’s not to say that SF Symbols or its implementation in these apps are perfect, but the more I re-read Tonsky’s article, the more I doubt his diagnosis that icon fonts are really as pervasive as he says, at least in native apps.
SF Symbols seems to be a font. There are codepoints that will render as SF symbols on Mac and iOS but they aren’t documented.
This is why I stay away from the Nerd Font project 😅
It’s easy to make jokes about this. But have you ever tried to design a layouting engine? It’s not as easy as it sounds. Some elements are sized or positioned depending on their contents. Other elements are sized or positioned based on the parent element. There is a huge number of dependencies between all the different elements and you, the layouting engine designer, have to make it all work out. In particular, you should avoid cyclic dependencies. And somehow communicate this to the person who uses your toolkit to create a GUI. Then there are issues where elements jitter back and forth because there is a bistable resolution to the constraints, such that the elements resize themselves and each other endlessly… And so on. It’s very easy to center one element in a simple and known context. It’s very hard to position all the elements in the general case.
I mean, okay, layout algorithms are complicated. (Although there is literally no excuse for “elements jitter back and forth”). But I find this attitude a bit pessimistic: you’re effectively saying that OP should temper their expectations because centering things really is a very hard problem, even relative to the ability of companies like Apple and Google.
That doesn’t quite ring true to me. Web browsers solve lots of hard problems. They don’t seem to have any issue with adding newer, more complicated layout algorithms that don’t help much with this. Also for some of these examples layout engines aren’t even in the picture. It seems to me that we probably haven’t solved this decisively because (a) not enough people care, and (b) it’s a problem with lots of causes that all need to be solved before we see any improvement.
You’d be surprised :-)
A classic case of this problem is websites that are just tall enough that a scroll bar may or may not appear - which in turn affects the actual page width. Various browsers have implemented various quirks to deal with this.
I’m not. OP should not temper his expectations. If he can do it better, more power to him. I wish him and everyone else who works on such problems the best of luck and a lot of success. All I say is that it’s easy to joke about it, but very hard to fix across the board. You can center Latin characters? Good. Now do the centering algorithm for literally every character combination in Unicode. What these problems have in common is that one single defined case is very simple, trivial even, but the general case is nigh impossible.
Came here to say basically this. Everything has to position itself relative to something else, and so with a complex layout there’s a lot of non-local data floating around. It’s also very easy to make positioning decisions that appear to work properly until something else changes, so it’s hard to find bugs.
Life was much easier in 1992 when you just hardcoded everything to specific positions on a 320x200 pixel screen. :-P
Has anyone ever attempted a “mass-based” centering algorithm?
I.e., instead of relying on bounding boxes for anything, compute the center of mass of the relevant pixels (pixels in font glyphs, non-transparent pixels in an icon, etc.), and layout based on that.
I can see it being expensive, but it should fix a lot of these issues iiuc.
I’m worried that the mass centring would be worse. As a contrived example, imagine three buttons labelled
If you aligned the centre of mass of the pixels, the top of M would move slightly up for each consecutive button. I expect that users would find it more aesthetically pleasing if the tops of the three letters were aligned.
I’m not sure about worse, though I’m now convinced mass isn’t sufficient by itself.
To follow your example, what if the letters on the buttons were “M”, ‘i”, and “x”? Aligning by top would make those look even less centered than by mass. (Baseline wouldn’t be too bad, but then that’s not centering.)
Seems like for those examples, you would just apply horizontal centering, not vertical. To align them vertically, you’d just align their ascenders and descenders. Am I missing something?
The alignment procedure you described is the proper solution. The only thing you’re missing is an idea that you probably rejected as too obvious to be the point:
Centre of Mass centring can be a useful tool in the alignment toolbox, but it doesn’t work as the sole alignment method for all situations.
Pretty sure that would be terrible for text, but it seems like a good heuristic for glyphs. What I see is that the visual center of mass is sightly different from the center of pixel mass. The goal IMO would be for designers to design their logos such that the center of mass of the bounding box is where they want their visual center of mass be, rather than to have the bounding box be as small as possible. It would be even better if Images could have 2 bounding boxes, one specifying the canvas size and the other one for laying out, similarly to descenders in fonts.
I’m not sure that would look visually balanced. Eg a logo that’s mostly one shape with a bit sticking out. Or take font: the center of mass would probably be slightly higher than the middle of x height but lower than the middle of the cap height to baseline interval. And a section of all caps would be different than regular text next to it.
I’m not sure this will change your mind, but to clarify: I’m suggesting the center of mass of the largest meaningful level, not individual glyphs.
As for the logo you described, maybe we could downweight by the distance from the center of mass, to minimize the effect of little hanging bits (e.g., Q)
For my font comments, I also meant the largest meaningful level. I’m saying if you took a line of text and got the center of mass, I would guess the center of mass of the whole line would probably be slightly higher than the middle of x height but lower than the middle of the cap height to baseline interval. When I say a section of all caps next to a section of regular text, I mean like in the examples in the article, where you might have two buttons or spans near each other: they’re supposed to be at the same “height”, but separate enough that they wouldn’t be calculated together.
I still don’t think the logo would work, because if we took a Q and a flipped Q, unless we weight the parts that stick out at zero, they’d be oddly jiggled. Or even take a square, where the top-left 1/4 is filled, vs the bottom-left in a different logo.
That button’s text is vertically centered: the lowercase letters that make up most of the text are within a pixel of perfect centering. It happens that the caps stick out less far than the descenders, so the glyph bounding box isn’t perfect, but that’s not really what the eye pays attention to.
Consider also that it’s really important to have baseline alignment of text in a row of buttons, so vertical layout can’t consider the individual glyphs in an individual button title; it has to use only the font’s metrics.
Well yes, but I feel like the article in question is trying to make the point that text should be laid-out as-if it were cap-height high, not x-height. And that ascender and descender should be a symmetric margin around that height.
Using the cap height to vertically align text doesn’t make visual sense when the great majority of the letters are lowercase.
And ascender and descender heights are up to the type designer and are not usually symmetrical.
When you consider accent marks too, things get even more confusing.
It’s kind of cute that a bunch of coders are thinking about these sorts of layout issues, but trust me, there are visual designers who know a lot more about this than we do. I’m not saying some of those examples aren’t terrible, just not the ones from Apple.
Harder than centering things? Centering others.
It’s a joke, but I do think computer science has an empathy problem. Unrelated topic to the article though.
The pointer sync (ptrs socket) got all my attention initially. May I ask what’s driving it?
This is the craft I love. Amazing article!
This issue honestly put me off web development for the rest of my life.
Okay, the inner, red disk is off-center in the outer, white disk. I don’t think I would have noticed if not for the zoomed-in picture. When it’s not zoomed-in, the difference is tiny. I do not believe this tiny asymmetry would prevent anyone from being able to tell that this is a “Record” button. I find this person’s standards too high.
Okay, the form input field’s label is slightly misaligned with the input field, but it’s still clearly attached to that input field. I find this person’s uses of “ruin(ed)” for these slight misalignments unsympathetically hyperbolic.
IF you- r aesTHEtic jdgment is a binary one based____on rcgnizablty & functnlty then this reply Is fiNe becasse u cn read it, right?
I can read it, but it’s much further from perfect than the “ruined” examples I cited, and it might not be understandable to readers with some but not full understanding of English, whereas I have difficulty imagining someone who knows what a perfect “Record” button looks like being unable to recognize the slightly imperfect QuickTime one.
(I acknowledge that this is not exactly an answer to your question.)
My point is that “recognizability” is not the criterion of quality. You’re setting a very low bar, just as the OP is setting a very high bar. In practice, something can be completely recognizable and usable while presenting an appearance of very low quality.
I was super confused for a second thinking someone else was controlling my screen or something was accidentally brushing the trackpad. Turns out the blog is just animating these fake cursors (look for
/** POINTERS */in https://tonsky.me/script.js).It breaks zoom too. I had to use reader mode to make the text a sensible size. It’s a pity the form detracts from the content.
What browser do you use? Pinch zoom on mobile and with trackpad on desktop work for me, Ctrl +/- works on desktop for me, I use Firefox.
On Safari the little A big A widget does not make the text smaller
I don’t know, Tsoding made it look super easy in C; https://twitter.com/tsoding/status/1752671189221150997
“No meetings or anything, just boom: centered”
Funny memes, but as soon as he adds text to that box he’ll inherit the problems described in the article.
What does this have to do with fonts?
You could always vertically center in CSS if you knew the height of the container.
I think “how to center 2 divs” might be my single most searched google term
i struggled with this until I stopped worrying and learned to love tailwindcss. Now I do “flex items-center justified-center” all the time.