Don't read this article, if you are not in web dev. Once you start seeing it, you can't stop seeing it, and it will drive you crazy forever. It is the same for noticing misalignment, recognizing color oversaturation, high quality speakers/headphones, etc.
I’m not entirely sure I agree with you on this. It’s hard for me to say because I really like the imperfections in things I build, for the most part. Like I’ll full spartle a wall (not entirely sure if this is the correct English description) and I’ll intentionally leave the finish less than “perfect” because I think it adds a little soul to it that will make me happy down the years.
Then you have things like flooring, installing windows, and anything on outside, however, where I’ll absolutely make sure it’s perfectly everything. Basically so my floors have none of the issues you describe as an example. Part of the success behind this is to hide the imperfections. You’re not going to ever build a perfect floor if you build it all the way to the wall. So what you do is that you leave a gap between the wall and the floor and you cover that gap up with wooden “footlists” (again not sure if that’s the correct English description). This gives you a “perfect” floor which aligns with everything in the room. The more crooked a room is, the more you have to cheat, but if you put in the effort it’s almost always achievable.I would like the small imperfections in these things as well. Ok, maybe not on the outside unless I was very sure it wouldn’t have an impact on the integrity of weather protection, but I wouldn’t mind crooked floors. The reason I strive to make them perfect is that other people won’t, which will make a property much harder to sell. Because unlike imperfect ”walling”, a floor correction/replacement will absolutely impact the value of a property.
But then there is the part where you will absolutely notice it when it’s not installed correctly. Which is what I guess you’re getting at, and I agree with you. The thing with buildings, however, is that you have to cheat. Buildings are imperfect and they can even more around a bit as weather conditions change. So with buildings you have to cheat. Which is different than with aligning things on the web, or at least it should be. So this is the part I disagree with a little.
As a side note people shouldn’t accept crooked floors and so on, especially not when you’ve hired professionals. They should know how to cheat.
> You’re not going to ever build a perfect floor if you build it all the way to the wall. So what you do is that you leave a gap between the wall and the floor and you cover that gap up with wooden “footlists” (again not sure if that’s the correct English description). This gives you a “perfect” floor which aligns with everything in the room.
“[Baseboard's] purpose is to cover the joint between the wall surface and the floor. It covers the uneven edge of flooring next to the wall; protects the wall from kicks, abrasion, and furniture; and can serve as a decorative molding.”
And commonly, in the US, you'll see baseboards (3-4" tall) which were sloppily cut and then that was, in turn, covered up with a quarter-round moulding. If the floor and wall are installed properly, the quarter round shouldn't be necessary.
It’s also to prevent moisture issues. If you plaster right down to the floor then the plaster slowly soaks up moisture over time. Instead an unsightly gap is left to prevent this bridging. Skirting / baseboard covers the gap.
So much of what happens in house construction is about water management and without understanding it, it’s common for people to create issues. Regularly see patios that cover airbricks, causing suspended timber floors to rot.
"Spartle" = Spachteln? You may trowel your wall (with a trowel full of plaster). At least that's what I do here in Canada.
"Footlist" = Fussleiste? Leiste is not a list. Leiste translated can literally just be "trim" and "foot trim" is quite close - leave out foot and you have what it's actually called. Floor trim, baseboard, baseboard trim (to distinguish from 'baseboard' just meaning 'baseboard heating' if context isn't clear etc).
I think your parent, like you are saying in the end as well, was also less worried about seeing your own imperfections (tho that's of course a thing too) and more in line with the original comment about "not being able to unsee it" in general.
And that is definitely true. You see all the badly hidden imperfections from professionals. And you will also see all the well hidden ones but you still know they're there now while before you did it yourself, you never even noticed. It can also make your relationship with professionals worse because you will see the hiding but have trouble distinguishing the correct line between "well hidden but visible to the professional eye" and "bad job" :)
> The thing with buildings, however, is that you have to cheat. Buildings are imperfect and they can even more around a bit as weather conditions change.
design systems are imperfect, and can become even more so with changing specs/frameworks/dependencies/browser updates/...
I’ve noticed these things all my life. Even as a young child I would point such things out and others would have trouble seeing it. Once I was diagnosed with autism, this tendency of mine made a lot more sense.
I’m curious if other people detect interrupted or irregular patterns so readily. It’s like there’s a part of my brain just looking for anomalies and I can’t turn it off.
I have this with grammar. When I read modern websites, articles, papers, emails from HR, etc. with their sloppy English and comma-splices everywhere, it annoys me way too much and it's a real challenge to push on through and keep reading.
It feels like walking through a maze, with an uneven floor and bad lighting, full of dead-ends, compared to walking down a pleasant, well-lit corridor.
I used to write some of the worst English out there. Then I became part in a streamers community, where proper English grammar was encouraged/enforced. (Well, more like having to at least try to write proper English, there was quite a bit of leeway) Ever since then, I get incredibly annoyed at people just writing "liek this and not giving an crap about proper grammar or punctuation this makes text harder to read then necessary"
Same. Also I get annoyed when pointing out (in good manner) misspellings, bad grammar, or technical inaccuracies gets called out as pedantry or policing, especially here on HN. Sure, it's not the end of the world - but the reason we have a nice place here is, in big part, because enough people care to set certain quality expectations. When that erodes, so do nice things.
This is spot-on. HR is bad, but at least writing is not their main job, so I'm willing to cut them some slack.
My main concern is the writing I see coming out of the Public Relations and Communications departments. Writing is not exactly tangential to those fields.
Maybe it’s related to how we (government, industry) used to routinely make great instructional videos and other learning materials, but are now largely terrible at it.
I suspect it’s all connected to the rise of a professional management class, rather than promotion through the ranks, and management by people who’ve done the work. Nobody who’s in a position to demand better or to make sure the right people are in the right roles, actually knows WTF they’re doing outside of a spreadsheet and PowerPoint.
It feels like there is a whole lot more cronyism and nepotism than I remember 20 years ago.
I am observing a lot of people in high paying jobs who don't have a clue how to do even the basics of their job (like being able to type proficiently in a job that requires written documentation).
This one is a bit more reasonable (to me at least). It seems to be an internet/texting convention that messages ending with a period are more formal/serious or potentially angry/irritated, whereas messages without a period are lighter/more fun. As an example:
“Have you taken the dog out?”
“Yes”
Vs
“Have you taken the dog out?”
“Yes.”
The second comes across as the responder being potentially irritated at the asker. I believe that this comes down to the amount of effort required to type the reply; adding a period is making the explicit choice to do so, whereas not doing so is the default. This isn’t the case for sentences in the middle of a multi-sentence answer, since a separator is needed anyways. But I find myself not adding a period even at the end of multi-sentence messages, and I automatically read any message ending with a period with a different tone than one which does not.
Maybe I’m just nuts though, that’s always an option. But with text being such a relatively limited medium for conveying emotion in short messages, I think this is a reasonable solution.
I have this with spelling. Even a fractional glance at a poster/billboard/sign, without focusing my eyes on it, and certainly without reading a single word ... any misspelled word triggers a flag in my brain sort of "pinging" me with the precise location of the misspelled word.
The grocer's apostrophe (which I will argue should be called the grocers'(1) apostrophe, since there are many offending grocers) is the bane of my existence
(1) My phone absolutely tried to correct that back to "grocer's"
If you want to make your existence slightly more irritating: Learn German and move to Germany. There the possessive s ending is written without an apostrophe - but there is an equivalent which then falsely writes the possessive with an apostrophe - the so-called Deppenapostroph (idiot's apostrophe).
What annoys me most about German vs English is that German has lots of English loanwords ending in "y" (e.g. "Party"), but it's officially not allowed to use the plural form that would be correct in English, e.g. "Parties" - you have to write "Partys". As a bonus, you could try using "Party's", but that would be incorrect again...
Well, it is "a baker's dozen", right? Not "all the bakers' dozens". Since the phrase incorporates a reference to a single individual, as a representative concept for all bakers.
So "the grocer's apostrophe" makes sense as a phrase referring to a typical individual grocer with a typical atypical apostrophe, standing in as a representative for all grocers and all their darned grocers' apostrophes.
Humans brains are pattern recognition machines. It’s how you are able to read efficiently, why you enjoy music, and why you are able to say “this alley seems shifty, best not enter it.”
Most people are able to naturally filter out most of it. You’re just a little less equipped to. People with ADHD have similar problems.
Psychedelics remove most of those filters, causing someone’s brain to get the raw data including all the anomalies in the processing, which makes patterns (visual and mental) both suddenly much more apparent and do weird things :)
My overconfident understanding is that "regular people" notice a "regular" amount, but let themselves forget about or ignore a "regular" amount of what they found. People with Autism are less able to let go of what they find, and often struggle with over-stimulation from it. People with ADHD start at an under-stimulated baseline, are instinctively looking for too much, and often overcompensate; which leads to a similar over-stimulation.
I'm autistic and I see patterns and issues with misaligned patterns which cause psychic pain. Also phase issues with sound because it feels physically painful.
I’m curious if other people detect interrupted or irregular patterns so readily
All the time, and I learned to not care a lot, even like some; for instance there's a lot of (mostly abstract, surrealism) art which does all the things wrong on that front but which is extremely enjoyable to me. Same weird way with music: exact 4/4 stuff is mostly boring, often even annoying, but give me funky off-beat stuff, chaos and noise and it brings a smile to my face.
There's only one thing which I can't shake off and that's lines which are meant to be, but aren't eaxcatly, parallel or right angles. Can keep staring at those. Especially when they are like very close to being correct but look like they're off (for like 1mm over 1m). Not the first time I actually get up and take a ruler to verify.
But then there is the intentional curvature in ancient stone columns, where ther the pillar is neither a perfect cylinder nor even a perfect cone, and it's on purpose because actual perfect forms don't look right to humans.
Like one part of the article shows the Apple logo in a circle, and the correct centering is not to have all points on the logo equidistant from the circle, but to allow the leaf to go a lot closer than the rest.
Is that autism thing? My therapist suspect I'm autistic, and I have always noticed things like this - or trying to align everything in my mind when I look at things, or trying to split the into two halves of equal volume.
>Is that autism thing? My therapist suspect I'm autistic, and I have always noticed things like this - or trying to align everything in my mind when I look at things, or trying to split the into two halves of equal volume.
Very much in line with being neurodivergent.
Sounds more like autism than ADHD, but it's hard for me to tell, 'cause I'm both[1].
Also autistic, I have this very much with displays. I can’t understand how people can stand LCD televisions. They usually have non-uniform brightness which is super distracting.
I was about to write: As someone late-diagnosed[1] with ADHD[2] and discovering they're autistic, ... -
>Once I was diagnosed with autism, this tendency of mine made a lot more sense.
...yup. This is what I was a about to write.
>I’m curious if other people detect interrupted or irregular patterns so readily. It’s like there’s a part of my brain just looking for anomalies and I can’t turn it off.
The answers to that are no and yes, that's the blessing and the curse of autism.
Seeking and recognizing patterns is one of the defining traits.
I haven't built/done any of these and yet notice misalignments and it drives me nuts. Hundreds of thousands of dollars (equivalent in INR) spent to on buildings and they don't bother to align bricks; it's as if there's no value in aesthetics, visual beauty, symmetry etc.,
Which I find very interesting. I’ve seen that there are constructors in India that are very much capable of recognizing and correctly implementing the alignments, but you pay so so much more than the average constructors- and then you are often in a conundrum where you have to choose between paying market rate and getting equivalent precision, or to pay 5x market rate to get a very good standard.
I deal with tradespeople on and off and I have a feeling the work quality has drastically reduced from say 30 years so. There are a bunch of contributing factors which I'm a bit tired to list down here. The net result has been that the person who does the final actual work (brick laying, wood cutting, painting etc.,) is almost always poorly skilled, are constantly cutting corners. Even if I'm willing to pay more than the market rate there just aren't such workers anymore. And it shows in the things that's getting built.
This is what causes me absolute task initiation paralysis - the fear of not being perfect - even with my new attempt at adherence to "don't let perfection be the enemy of good enough"
Does anyone else who comes into the house notice anything? Very unlikely unless they are craftspeople.
Here's how you do it, make everything so poorly in terms of fit and finish that it becomes hard to find things that are perfect (or even good). Embrace the aesthetic.
I thought the tiles on my bathroom floor were perfectly flat and even on the ground, until I switched off the light and used that damn laser on the Dyson vacuum cleaner.
What greeted me was an uneven landscape of tiles that the naked eye just didn't see.
Same, except with panel floor in our bedroom. Moved the bedframe and some cabinets around, suddenly the bed is really wobbly. Couldn't see why until I took my laser level and started sweeping the floor with the "red X" at a low angle, like it was sci-fi scanner.
That laser level actually revealed plenty of places around the apartment I dare not look at anymore, lest I get annoyed at the contractors... and the original builders of the block.
For me it was 3D printing. My vision started to occasionally annotate and code-suggest on real world objects. I kind of wish I didn't realize just how much we're enabling M3 screws.
My house is built on top of bentonite clay (I think that's the term). My doors would stick if there weren't gaps. I have a system where I measure the level across the house and adjust my teleposts every year too.
Doors. That one is a double whammy, because even if I force myself to unsee that a wing was installed unevenly, eventually gravity itself will remind me, as it will start closing on its own, or stopping at a different angle than other doors in the house, etc.
I can attest to that. Painting doors and then watching the result is akin to watching a good painting/desktop background for too long... as time passes you start to notice the irregularities. Like the girl's hand is overly big, or her legs are exaggerated.
I just patched a whole bunch of drywall cutouts after having some electrical work done. Now I when I look at a new construction house, I can tell which builders use go cheap on drywall, esp. when there's too much texture.
Tiles. There is a correct way to install them. I don’t know how you decide what’s correct, but sometimes it’s centred, sometimes a full one on the left, or the right.
Then you have the same scenario but top to bottom.
When we were building our house I built a tool[0] for exactly this problem so I could visualize how tiles would look w/ different arranging. Worked really well for both floor tile and tile on the shower walls
I was looking for something like this when redoing my bathroom tiles but surprisingly couldn't find anything. I ended up using draw.io which worked but not that easily.
A few suggestions for your tool. Add millimeters as an option. I'm using 12"x24" tile for the floor but they're really 300mm x 600mm. I learned most 12"x24" are that size. Another thing I learned is with that size it's recommended to use a 33% offset pattern. This guy explains it well https://www.diytileguy.com/12x24-tile/
Bicycle handlebars and brake levers alignement. This can drive you crazy...yet nobody has 2 arms the same length so perfect alignment shouldn't even matter that much.
Truth, I spend every free second in an Airbnb analyzing their trim, electrical, flooring, et c work. Spotting where additions were made. Can’t turn it off.
I wish I had never heard of kerning! I wasn't even aware that I was sensitive to kerning issues until this abomination came into my house: https://th.bing.com/th/id/OIP.bdzKtgJ5MkGpA5iutzfTxQAAAA?rs=...
Now, whenever I see that thing, I feel a sudden urge to throw it out of the window...
Former frontend developer here -- I did fight with these misalignments (typically those things that don't align were lots of nested containers, fighting with each other in different ways, so the solution was to clean them up and use one simple alignment).
But I stopped noticing these things, maybe because mobile UIs are a lot worse -- not in visual design, but in that they always do weird things and live their own life.
Misalignment is a tiny dirty spot on a clean but wrecked car.
That cleanup was done in a small company, where it took just 1-2 hours. I was in full control because I out-argued others for my CSS styles cleanup, that they didn't like. In my current place, I bet this will take couple of days if you really try hard and care and nobody is against. I think, in big organizations, either there are somebody against this, or people stop caring that much to push these changes.
Several years ago I spent around 2 weeks on fixing antialiased font rendering in a game engine. Had to look close at the text in other apps to compare. Took me months to unsee it
I just went through all of the easy ones and most of them seem "obvious", but some of them seem like preference (like the separator width). Another one I noticed is medium 6, where I'm not sure the smaller icon is necessarily always better. I'd be careful taking something like this as gospel without careful scrutinization. A lot of it feels like modern UI dogma which likes to waste space for no reason other than aesthetics, rather than actual UI research. Some of it just feels completely arbitrary.
I accidentally did something similar to a college friend when I pointed out the 15khz hum that televisions made. He had not noticed that before and then couldn't stop hearing it.
relatively . Till you take things into your own hands and fix that pesky button with extra padding on top. Huh how hard was that! Lazy devs.
You just entered the mystical world of undocumented browser behavior where every browser does its own thing. The button looks ok on chrome, but safari's borders are more round making that look still off. You won't back down, and take on this challenge, make it look great on chrome and safari too. Yay! Worth the 2 hours eh.
Up rears the monster of responsive design... it doesn't work well on safari on the phones now. Well it works for me you say, till you rotate your screen and the button is Gone !
You finally succumb and say screw it, i'll just stick with html and get back to scrolling hn.
As great as it is, it still sucks because on my full-screen browser, the text spans the entire monitor width, which makes text hard(er) to read. But as soon as you start forcing narrower columns for better readability, you start to run into positioning and precision problems again.
If there’s anything I learned from studying design and typography, it’s that there’s no singular correct rule you can use to align things.
Use precise measurements for your margins? Someone will say that perceptually it’s not symmetrical, and rightfully point out that perceived symmetry is the only one that matters. Adjust visually for your hanging punctuation, ascenders and descenders? Someone will draw a bunch of red lines and complain it’s not perfectly aligned with baseline, x-height, or whatever they prefer.
GUIs around us are rich with obviously broken examples where spinners spin out of their centers, text in boxes is misaligned, etc. However, as articles like this one show, even if every one of those is dealt with, us designers will still have everything to complain about. (Pro tip: if you struggle to find something to complain about in the English version of a GUI, just switch to, say, Arabic.)
Jup. Somw people like to think centering things is taking the bounding box of the visible pixel and centering the center of the bounding box. But some letters have more pixels in one half or the other, so that would leave you with more whitespace one one or the other side. That means despite being metrically centered it still doesn't look optically centered.
I guess one could devise algorithms for that, but I haven't seen one that does a better job than my brain and my eyes.
The problem with your brain and your eyes are that they aren't available after the user picks their preferred font or for user-generated content or probably not after the text had been translated.
> Somw people like to think centering things is taking the bounding box of the visible pixel and centering the center of the bounding box.
That was my naive understanding for probably my first year at the uni. It got cleared up fairly quickly.
I imagine there can be typesetting/layout styles where this holds, but I would classify them as niche (maybe brutalism or something like that).
Funnily enough, in the very first example under Fonts I thought the author didn’t like “Manage…” because it could be pushed slightly to the right (due to ellipsis), but it turns out to be about vertical alignment which I didn’t see anything obviously wrong about in that particular case.
Once you deal with the obvious cases of lopsidedness in your design, the important quality becomes simply: stay consistent. Here, no self-respecting designer would pull one random example and say it’s wrong—you have to assess in context of design model as a whole, where you can either 1) show how one particular button breaks the model, or 2) argue that the model is wrong (which can be done, but good luck).
This vertical centering of text in buttons is more noticeable when there is an icon next to it. But it drives me crazy that the default is not to center around the cap and baseline. This is what I usually see in figma designs and it looks the best, but it's not simple to apply in html & css.
If the button is not in all caps, i.e. the first letter is substantially taller, then aligning by baseline & cap would make the text as a whole look too low (depending on x-height).
Icons can be less ambiguous, but still it depends on the shape and white space within one and the interplay with text label.
I think it all depends on your vision and its consistency.
You can actually still do it. Just don't measure until after the fonts and elements are in place. dynamically adjust the position afterward. There is no rule that says you must use only CSS
Indeed I think the advice around calibrating fonts is not going to work if the text is long or has an unusual arrangement of ascenders and descenders. The reality is that centring is very context specific.
That's because CSS layout was designed by people who thought "float" and "clear" were a good idea, tables were bad, and, when in doubt, make it Turing-complete and dump the problem on someone else.
2D and 3D tools get this right. CAD programs, game engines, and animation programs are all far better at positioning things. They have far better layout engines and constraint systems. This is really a constraint problem. Autodesk Inventor and Fusion 360 have good 2D constraint solvers, ones that can put something on a centerline, or parallel, or whatever, including curve tools. Webland never got that far.
Man... whole generations just straight up either do not realize, or have forgotten that early CSS revolved around creating documents, not apps, and that all of those design paradigms originated from typesetting.
In the same way that one would float a figure to the left or right of lines of a paragraph, `float: left;` and `float: right;` allowed you to do the same.
Open a textbook and look at lines of a paragraph flowing (where content "flow" layout comes from) around a figure, such as an image or a diagram.
The World Wide Web was documents.
In this context, `float` was a genius idea. There's literally no other way in CSS to do this without a bunch of hacks.
Honestly, that itself sounds bad too. The concept of floating sounds like something invented back during manual typesetting or earlier.
I think anyone ever trying to write a paper or book with images in it using tools like LaTeX knows how bad it is to let the tool position images for you. It's always wrong, and one of the first things you learn is how to pin the image in between the text lines/paragraphs you wanted it to be between.
Text-to-diagram tools like PlantUML (and arguably even Graphviz) make this mistake too. The moment you put more than a couple things in your diagram, you discover that auto-layout can't ever make the result readable, and you look for ways to pin parts of the diagram relative to other parts; something these tools don't let you do either.
And then all three classes of tools here - HTML, typesetting, diagramming - violate the principle of least surprise in the nastiest of way: make one little change, add a letter or word somewhere, suddenly the result looks nothing like it was before, as the auto-layouting flips everything around.
A lot could be said. If there's a mistake, it was the economy not providing sufficient resources to solve this problem well. There was certainly awareness of this topic and some attempts to address it (for example North, Stephen C. "Incremental layout in DynaDAG." International Symposium on Graph Drawing, Berlin Heidelberg, 1995, or North, Stephen C., and Gordon Woodhull. "Online hierarchical graph drawing." Graph Drawing: 9th International Symposium, GD 2001 Vienna, Austria, Springer Berlin Heidelberg, 2002.
Successful systems like Tom Sawyer Software or yWorks have dynamic or incremental layout features. The market of course strongly rewarded work on interactive systems like Visio that were well integrated into larger platforms.
Not sure who remembers but high performance incremental constraint-based layout was one of the computer science lights that failed in the 1980s and 90s but with so many fundamental advances in technology (processors, algorithms, solvers, software platforms) and new emphasis on language-based approaches (in part due to LLMs) there might be a better opportunity now.
Anyway it's a hard problem, it's not as if nobody was aware of it.
But that is the fundamental problem behind all of web nowadays: It was initially designed for documents; there are precursors for this entire HTML stuff (hypercards and similar things). Funnily enough, there existed tech even back then that was much much better at dealing with actual applications and their requirements. Unfortunately, many stupid idiots decided to use the "web" for that instead and mangle something aimed at documents to hell and back to actually do apps with it. The amount of time (of humans) and resources (not humans, but computing power, energy, ...) wasted on creating and running kludge after kludge to coerce the "web" into "something for apps" is absolute insanity.
They weren't really idiots, though, that's quite harsh. People wanted to be able to share software but there were so many barriers to entry at the distribution/installation/update phases that they used the solution that didn't require any of that.
It was a hack but it worked better to serve the needs of the users.
Come on, there are so many native cross-platform solutions which are easy to go and much less bloated than web engine, e.g. Qt/GTK+/wxWidgets/Xamarin/etc.
Yes, this is how classic software works. It can download updates in the background, just like e.g. web browsers do. It will be more performant than web apps.
That's quite a lot of extra code to write. Any app you want to share this way now needs to think about networking, self updating, version management etc.
Now take that beautiful application you have made and your customers want, and beg the trolls who sit between you and them for permission to distribute it.
Assuming you get said permission some weeks later, now hand over double-digit percentages of your top-line revenue to these despicable rent-seekers, do the same with your tax payments and notice how you're left with less than 30% of the value you have created.
It is a weird myth that CSS somehow discourages tables. CSS have supported styling html tables and ‘display:table’ (allowing a table-like layout without html-tables) for 25 years.
Float and clear was grandfathered into CSS since they were added to HTML by Netscape. They are fine for their intended purpose: placing images in a text and have the text flow around.
Other positioning systems you mention does not solve the same problem as CSS. CSS has to support viewports of any size and dimensions and allow text to scale independently of the viewport size and still remain readable.
>It is a weird myth that CSS somehow discourages tables. CSS have supported styling html tables and ‘display:table’ (allowing a table-like layout without html-tables) for 25 years.
Not a myth in any way shape or form. Tables for layout (not tables in general) were discouraged with various arguments in favor of "float/clear", even decades before a sane substitute (grid/flex) was available.
>Other positioning systems you mention does not solve the same problem as CSS. CSS has to support viewports of any size and dimensions and allow text to scale independently of the viewport size and still remain readable.
None of those requirements is unique to CSS, and none of those requirements necessitates the stupid float/clear mechanisms that were shoved into people's throats for 15 years.
We're talking about the style language that had layout shoe-horned into it, and which tool decades to develop the most basic layout mechanisms available in GUIs for decades, grid layout and flex layout. And even when it did, it didn't it badly.
> Tables for layout (not tables in general) were discouraged with various arguments in favor of "float/clear"
Table markup was discouraged. There’s nothing intrinsically wrong with display:table from a CSS/semantic markup evangelist’s point of view, it’s just awkward to use, requires you to arrange and order your markup just so (sometimes contrary to semantics), and was rarely mentioned in the days of float/clear because IE screwed it up in various ways (that were more difficult to fix than those for floats). It works reliably now, but as far as laying out the page goes the requirements for ordering the markup will probably be incompatible between desktop and mobile. For insides of buttons and such, though, go nuts.
CSS never recommended float/clear as an alternative to table-based layout. CSS had ‘display:table’ for when you needed a tabular layout without the semantic baggage of the table-tag.
CSS, as in "CSS evangelists", influential web designers, guidelines in web development resources, books, and so on, recommended and advocated for the use of clear/float.
You might not have been there, but float layout was a big thing back then, and everybody was guilt-pressured to use that - neither tables, nor "display: table" (which was used by some, but also discouraged).
You are probably remembering advice from the dark age of IE6 dominance where display:table was not well supported. I have also seen advice againt using html tables in the early days of mobile browsers since they handled them badly.
The problem is people forget context. The advice “dont use tables <in this specific context under these specific constraints>” is remembered as “tables are bad, never use tables or anything which remotely looks like a table”.
'display: table' wasn't consistently supported and '<table>' for layout caused issues for screen readers because they (rightfully) expected content that's tabular in nature.
Nobody was guilt-pressured into using floats. You might say some were guilt-pressured into writing accessible web sites but that is a significant destinction. Many public/government web sites were mandated by law to be accessible, so many developers had to write accessible html whether they liked it or not.
Of course for your personal Tranformers fan site you can use html tables to your hearts desire. Nobody is likely to complain.
But most web-design focused media is targeted professionals for whom it is a necesssary skill to be able to design pages which look good for most users and is accessible. During the dark age of IE6 it was necessary for developers to know and use a large array of hacks (including the abuse of floats) to achive this.
What, no? I did a lot of web development in those days and read a lot of blogs. You just needed to filter out anyone who was obviously over-opinionated and lacked any nuance. Most pragmatic people used tables and didn't feel guilty about it. If you delivered working software with a decent UX, why on earth would you care what some shouty internet person said??
Oof - I didn't know that. Kind of a weird requirement, were/are screen readers rendered so ineffective by the content being in a table as opposed to in divs?
Not inneffective as such, it just presented a confusing user experience because the screen reader would assume the table represented data structured in two dimensions and e.g present navigation options for going cellwise left/right and up/down.
This would be pretty confusing if the table was just used to create a margin and most cells only contained spacer gifs. Especially with deeply nested tables (as was the fashion at the time) it could be pretty confusing.
Today you can just add an ARIA-hint indicating a html table is used purely for layout and a screen reader can then treat it just as divs. But this did not exist at the time.
Of course the WCAG just assumed it was not a big deal to avoid tables for layout since CSS2 supported tabular layout through pure CSS. But the reality of a web dominated by IE6 made this a much larger problem.
"CSS" (not sure what you're referring to here, the standards bodies?). Endless articles from the mid 2000s kept saying tables bad, here's how you layout without tables. All of them used floats for layout, not display:table. Partly I suppose this was because IE didn't support it until 2009, I think.
Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.
> Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.
I think this is the core misunderstanding in this discussion. CSS 2 supported both text-flow and tabular layout and both layout models were reverse-ingeneered from how Netscape rendered HTML.
There is this weird idea that CSS is somehow opposed to tables or tabular layout, while a significant part of CSS2 is actually the codification of how tables render.
I don’t think there’s much of a misunderstanding here. There are historical reasons why CSS was so weak on layout for so long, but there’s always reasons. To understand what was missing look at what they’ve added (flexbox and grid). I don’t like the implementation of either, but they are in the right space.
The reason for the advice against tables was that the "semantic web" was all the rage (probably mostly because Google wanted to make it easier to index stuff). If you have tabular data, using tables was just fine. The issue was with using it solely to control the graphical presentation without any semantic basis for putting it in the table. Same reason you don't use <H1> just to make the text bigger.
>The issue was with using it solely to control the graphical presentation without any semantic basis for putting it in the table.
There shouldn't be any semantic basis needed.
HTML is not a semantic data exchange format, was not designed to be (the pathetic handful of semantic HTML5 tags added to be used ad-hoc included), and it inevitably includes content, style, and behavior (js).
The semantics should belong to data intergchanged (and storage format), and the reusability should be on the data storage/query backend, not to the markup language.
Adding semantics to the markup duplicates the semantics already present in your DB or JSON API scheme or query server/storage in general.
Yeah there was a period of time when IE didnt support display:table and ARIA hints wasnt as developed. So if you wanted to create accessible web sites with nice layout you had to resort to weird hacks, often using floats.
Floats was never intended for that purpose though, it was just a desperate hack to get around IE limitations.
But html tables was not a viable alternative for organizations which was required to have accessible websites.
(Today I believe it is possible to create accissible html tables through ARIA hints, but that was not an option at the time.)
Meh, discouraged by some bloggers, sure. Those of us doing web development in that time (I built some pretty large websites in the days before flexbox) ignored obviously overbearing advice like that. I still occasionally use tables for layout, even when something isn't 100% a grid of data. Granted those cases are quite rare and generally flex is the right solution.
Before CSS people used to use tables, often nested, for all kinds of layout. Eg if your page had a header, a sidebar and a main text area, you would create a table with cells of the right relative widths, with invisible borders, and put each layout element in one possibly merged cell. This was essentially standard practice for a while.
CSS allowed layouts like this to be done without tables. It still supported tables, but for the case when you actually want to show tabular data which would appear like a table on the page.
And then it took some 20-ish years for CSS to finally realize that aligning to a grid is a good idea and, through a long, painful, incremental process, eventually reinvent tables for layout.
I mean, semantics are also good! Yes, CSS grids are a lot like tables in some ways, but not having to add 25% more DOM elements to fake a table layout (display: table/table-row/table-cell; that's 3 divs for one row!) is also a thing to be celebrated. Plus, in practice, grid is a lot more powerful than doing a few common layouts. Grid took so long precisely because they were trying to think a little further ahead rather than just pushing something out into the world and hoping it works out. Thankfully web standards have matured and are more careful not to repeat mistakes like the debacle that was CSS property prefixes.
>I mean, semantics are also good! Yes, CSS grids are a lot like tables in some ways, but not having to add 25% more DOM elements to fake a table layout (display: table/table-row/table-cell; that's 3 divs for one row!) is also a thing to be celebrated.
Semantics in the context of CSS is a stupid idea web designers came up with. They heard the concept of "semantic", and had to fit it in, to appear smart. Should have asked actual developers.
(the so-called "semantic web" was another such failed idea dragged on for an eternity for research grands. Remember RDF? What fun!)
The semantics is not the job for HTML, which is the final artifact for display, and not a data interchange format, nor the format you store your info as. So there's no need for it to be semantically clean and "parsable/reusable" (to do what? web-scrap it? As for screen-readers, there are official metadata annotations for those - not to mention they wouldn't know to do anything special for each ad-hoc different "semantic" tag soup people come up with with the severely limited for that reason HTML5 tags, or worse divs).
The semantics belong to whatever backend and metadata you have your content in, before it gets rendered as HTML.
And if you need to also give it to users in parsable/reusable form, allow them to query a JSON (or structured) version.
Yeah, it's a joke. You can't take "HTML semantics" seriously when you often depend on actual element position IN THE HTML CODE to make things work, specially when modern web design demands elements to just JUMP AROUND all over the page when the width changes.
If they really wanted semantics you would think there would be actual support for that.
By the way, I've asked this question here some other day, but nobody has any idea if most "semantic" tags are being used for anything at all (and Wordpress naturally uses all of them wrong, so there is no point even bothering).
There's not much software that takes semantic HTML as input, because barely anyone writes semantically-valid HTML. It's a vicious cycle. (Look upon the parsing rules for a high-quality screen reader, and weep.)
No point making a semantic web browser before we get a semantic WYSIWYM HTML editor. Maybe those could be the same program, like in olden times?
> but not having to add 25% more DOM elements to fake a table layout
I'm not the most current, but as I remember in CSS tables those table-internal elements generate the needed anonymous boxes of rows, tbodys and such, when those arent't specified:
Nah, semantics are worthless. The whole semantic web idea never took off for good reasons, HTML5 semantic tags don't have any meaningful semantics and you can't even reliably remove boilerplate from HTML without ML pipelines (a basic use case you'd expect any "semantic" document format to nail easily). Then the invention of LLMs killed it twice over.
HTML is a graphics rendering language in denial about its true nature.
Grid took a long time because everything takes a long time when you have to align mutually competing organizations and there's no profit motive involved with the actual work itself. There's no real technical benefits to CSS layout over table tags. A table tag isn't a heavy object. CSS cascade calculations on the other hand ...
I suggest you spend some time with a screen reader or have a look at the accessibility tab of you browser to get a feel of the worth of semantic web.
It's true you won't ever have a perfect semantic representation of a page (and I have no idea how blind people manage those infinite scroller), but in my mind having <nav> or <div role="nav"> instead of <div class="my_non_standard_nav_classname"> still helps a lot on that aspect.
I use Shortcat all the time which relies heavily on the accessibility tree.
Screen readers / accessibility tools don't use the semantic web. The semantic web doesn't exist, it refers to the Tim Berners-Lee vision of documents being XML or RDF data structures with schemas, transformed into pixels using stylesheets and XSL:T. It never happened for various reasons.
CSS tables can have grid-auto-flow as dense, which is quite helpful at rare times. You obviously could do that wit tables + js, but it's nice to not have to worry about the implementation details.
Funny thing is that it still easier, even today, to use a frameset rather for header, sidebar and main area rather than fiddle with the new grid system.
Use position: absolute; or position: fixed; for both header and sidebar. Main area gets margin as big as header and sidebar. No framesets needed. That's at least what I did in 2001 and it worked like a charm. Even matching background elements of header and sidebar without any gaps.
They are still supported and works perfectly fine still. Remember that browsers supports different DOCTYPEs (HTML5, XML, HTML4 strict and non strict etc) and they are not going away anytime soon, probably thousands and thousands web sites out there that doesn't implement HTML5 and never will.
Frameset is deprecated in HTML5, but your index page can be of the older frameset DOCTYPE and each frame valid HTML5 page with a <!DOCTYPE html> declaration. This is why frames (and iframes) are actually great because you can mix old an new.
I absolutely remember a ton of pieces about how we all needed to stop using tables (and 1x1 transparent gifs, too) for page layout because CSS was The Right Way
The issue is people taking “tables are bad for non-tabular layout” and just remembering the first three words. People like stark binary yes/no rules, so “tables are bad” was born and spread widely.
If your layout is intended to be a table, then a table (styled with CSS) is the way to go, otherwise use semantic HTML (styled with CSS) and you will (in theory) have an easier time making the design work well at different sizes/resolutions and in alternate UAs like screen readers.
Exactly this. People need to think critically and not just blindly follow whatever some popular bloggers are saying.
It's the same today though - half of HN is utterly convinced rebellious technologies like HTMX are going to save us from the evil of front-end libraries. People adopt guides or entire technologies without ever actually building something significant with them.
There is always a lot of confusion about this because “tables” can mean different things - it is both a set of structual elements in HTML and a layout model in CSS.
CSS is “the right way” to control styling and layout, but that does not mean you can’t use tables.
In the early days of the web people used the BLOCKQUOTE element to create margins since this was the only way. When CSS arrived, it became “the right way” to create margins - but that does not mean you can’t use blockquotes! You just need to distinguish beteen the semantics of a quote and the layou effect of margins.
But I’m sure someone understod this to mean that quoting things were bad.
But that is the point. CSS arrived, and people started saying you "just need to distinguish beteen the semantics of" a table "and the layout effect". Back then, the chant of the day was, "blood for the blood god, tabular data for the <table> god, layout for the CSS god".
And then it spiraled into general "separation of content and presentation" nonsense that, like in any good cult, people believed with their whole hearts, preached to make new converts, then did the opposite because reality demanded it, and couldn't see the problem. CSS Zen Garden notwithstanding, we ended up with div soups (later, semantic div-equivalent soups) inseparable from complex CSS, because form is function; your content is always designed with a particular form in mind.
Layout tables were never a serious problem for screen readers, this has always been overblown. Screen readers adopted working heuristics to distinguish between layout and data tables early on, because tables were used for layout almost from the beginning (as soon as it was possible to remove the visible borders).
See for example WebAIM https://webaim.org/techniques/tables/: “It is sometimes suggested, even by some accessibility advocates, that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues.”
Google never had a problem working with content that was blended with it's visual presentation. They literally doesn't care. They crawl anything even pdf and other non-html content.
The semantic web was born from a belief that it would enable a peer to peer web that never materialized. Accessibility was better solved by aria annotations a long time ago and the semantic web was never going to properly solve it.
FWIW, it's hard for a peer to peer web to materialize, where the web is almost entirely built and funded by entities who very much don't want a peer to peer web, and in fact actively fight it.
> How could Google even work if content could not be seperated from its visual presention?
Approximately. Like it did and does.
The simplest way is to just strip the markup (or, for purposes of indexing, just ignore any token that resembles a HTML tag). That'll easily get you 90% there. You'll lose important information that's tied to form, but that's a consequence of operating in plaintext land. If doing this to build an index of the web, you'll have problem with scoundrels stuffing irrelevant text made invisible to humans by markup/CSS/JS, but that's exactly the problem Google used to have for a long time, and the essence of what SEO is :).
It was a much saner, simpler, and more efficient mechanism that the clear/float monstrocities imposed upon people in the period before grid, which reinvented the same thing (table layout) just without the actual tags.
display:table was never really evangelized for tabular layout. They were pretty much ignored and the literature and documentation missed the point. Tabular layout is really just another word for grid layouts. Grid layouts took forever to arrive. Tables were the only reliable way lay things out in a grid for a very long time and yet were discouraged regardless. There were people who knew about display:table and used it and some of us were nevertheless told we were doing it wrong because people got hung up on the word table.
Like many things in CSS features that should have been present in the original 2.0, when it became clear that the web wanted to be laid out like a magazine, Took multiple decades to actually appear. As a result we are still seeing the fallout of those failures in our ecosystem.
I'm saying that CSS has always had really confusing messaging around what is considered good practice and what is considered bad. If CSS had actually had the equivalent of Go's stdlib and documentation with well established good practices that were pragmatic we would be having a very different conversation right now.
They shouldn't had mean, they should had said that.
Because 99% of time we have a bunch of <p> in assortments of <div> representing a tabular data. Dozens of "web" "front-end" "frameworks" doesn't help it in any way, too.
Yes, table for layout and table for tabular data is different things. This was usually very clear in advices. Don't use <table> for layout. DO use <table> for tables.
Except for (vector) graphics design, desktop publishing, page layout designing and reporting software...
The reason is of course that most printed items are unica and non-variable, but
proper parametric and constraint-based would definitely be useful in report generation and signage where print formats vary or where designs need to be automatically adjusted based on texts and other content varying in size/length.
Do the tools you say do it better than html also handle the variety of clients html documents are expected to work with? Or handle accessibility better?
XAML/Silverlight was pretty fantastic. Significantly more sane layout model (by virtue of having more than a mote of sanity at all). It did handle a very wide gamut of clients during its time.
Why? Because it was designed for creating apps, not documents. HTML is great for creating documents, most of the examples in the post are not documents.
I don’t think it was that tables were bad. They were too formulaic and too strict and it was hard to do something that would stand out.
With CSS it wasn’t dumping problem on the others, it was giving the freedom. Problem with freedom is that it is never free and you also have to fix additional problems that come with it.
The problem I see with using tables for layout is that it fucks up the semantic meaning of the html file.
But that was an issue of philosophy that got trumped by practical needs.
However, nowadays we have css grids with template areas. So we can just write our HTML semantically correct as if it was more or less just about the content (as it should be IMHO) and still move things around using CSS depending on the type of device, size of screen, media used.
So the holy grail in my opinion is to write HTML that contains only content and metadata and next to no elements or attributes that are needed purely for semantically irrelevant layout and styling purposes — and then do all the layout and styling in CSS. Styling tags like <em> or the occasional <section class="notice"> are okay, one should never be too strict with such ideals.
The advantage here is that this provides the maximum decoupling between the content and the layout/styling which not only helps with future layout updates, but improves the accessability of the page.
One thing I also seem to remember from the very old days, was that browsers wouldn't render the table until it was completely downloaded. So if your whole content was in a table, there would be nothing to see until the whole page was loaded and it could do the layout. But without tables you would see parts pop in as it was loaded.
I've seriously considered doing websites in pdf too but still have to run into a situation dramatic enough for it to be worth it. Now that I think about it again "installing" a pdf on a pc could cover a lot of app like functionality. Most important is to make it as convenient as possible to remember your business exists and interact with it.
active (PDF) documents seem to have become a thing on eReaders, especially pen-based ones; mostly they leverage clever linking and bookmarking, and not much more, though.
I think (despite the article’s digs) iOS had the right idea with everything having a relative layout to parents and siblings. It makes it much easier to know what “center” actually means when you have a notion of what it’s supposed to be centered to.
They probably thought we would ditch HTML/CSS for something better but then PHP came around and fixed many of HTML's shortcomings and then AJAX came around and we kept sinking DEEP into this fundamentally broken ecosystem and now it's just too late to leave.
Although, honestly, how hard would it be for Chrome to support some new language called Super Text Markup Language that is designed for modern use with support for templating, portals, actual semantic layouts that don't rely on position on the code, etc.? Perhaps it's time.
> Although, honestly, how hard would it be for Chrome to support some new language called Super Text Markup Language that is designed for modern use with support for templating, portals, actual semantic layouts that don't rely on position on the code, etc.? Perhaps it's time.
"Google Web". Like what Google did to USENET. First they connected to USENET. Then they called it "Google Groups". Gradually, free USENET declined, and now, there is only Google Groups.
It would be so much more convenient. No more need for hosting providers, domain services, and most of AWS. Just host on Google Web.
It would be very hard and inconvenient to backport indeed. But webdev has moved much away from the initial HTML world anyway, so I believe it might be possible in a completely alternative rendering stack.
Funnily enough, Unity's latest UI approach is to just use web tech, with their 'UML' XML dialect plus CSS-like styling via the yoga embeddable C++ flexbox renderer.
Also, Fusion 360 is now known as just Fusion (it's cleaner that way?)
This is an excellent piece, about how virtually impossible it is to center things accurately mostly because of how fonts are displayed.
But I'll add two more wrinkles that the author doesn't mention:
First, that font rendering isn't just about metrics but varies across operating systems and browsers. So even if you center perfectly on Chrome on your Mac, it may very well be off on Firefox on Windows.
And second, that the author's proposed solutions only work for Western-style fonts that have ascenders and descenders. It gets even trickier when you consider a range of totally different scripts from Asia etc.
Yes, and let’s not forget fallback fonts. So rules for each browser and OS and each font class and each layout (desktop, tablet, mobile). Probably on the order of 100 rules for a single style. Yeah, we’re just being lazy.
We need sane font rendering in browsers that treat things like alignment in a way that we’d expect for the 99% case. If I say “center” it should just fucking center.
Fallback fonts are a legacy of the past though, in an era where everybody ships at least hundred of kilobytes of JS and images (when it's not tens of megabytes, but this is another topic…) there's no good reason to specify a font and hope it will be found on the customer's OS: ship the font you're using.
No thanks, I don't want your shitty font file that only looks ok on whatever system you testet. All websites should use the system font for body text. The only problems is that a) the default browser font is usually some ugly shit instead of the system font and b) there is no way to specify size in a way that different fonts will actually be the same size. Both of these need to be fixed in the browser instead of hacking on more shit for each website.
> No thanks, I don't want your shitty font file that only looks ok on whatever system you testet.
Why would it looks bad elsewhere?
> All websites should use the system font for body text.
Wait what? There are very different requirements when it comes to reading system widgets and actual text! (like we don't use the same kind font for code and prose).
Which is why I've configured my browser to use the correct fonts that work for me. Use `font-family: revert;` for prose, and `font-family: system-ui;` for any widgets you've got.
I'm probably in a tiny minority, but I just flat out disable third party fonts. Everything looks equally good to me and I save bandwidth. The only expression are image fonts, which render as squares - I share the author's frustration.
Third party fonts are a privacy nightmare, especially when you know who's the biggest third party out there. But there's no good reason to source the fonts from a third party either: you can host them by yourself and serve them with the rest of the website.
Now disabling custom fonts altogether makes sense of you are trying yo save bandwidth, but then you aren't mad if things don't properly align.
You don't need 10Mbps to download a 30kB font file.
And if you're really targeting people that have trouble loading such a font file, then you have much, much bigger problems than centering things (you basically cannot put any image on your website).
> A 30kb font file kinda website is probably gonna serve a 2Mb all up web page
Where's that ratio coming from? Shipping fonts is just good practice when you want your website to look consistently on all platform, it doesn't mean anything else about how the website is made.
Also, 100kbps is a very slow connection, it's 2 orders of magnitude less than the 10Mbps you talked about earlier, and when you have this kind of very poor connection everything is kind of slow anyway (even the very barebone HN's front page is 120kb!).
> First, that font rendering isn't just about metrics but varies across operating systems and browsers.
This is in parts, however, due to font metrics, because Windows and Mac use different conventions of how font metrics are specified in fonts: https://www.williamrchase.com/writing/2019-11-10-font-height...
In other words, the usual font formats don’t specify font metrics in an unambiguous way.
> That’s exactly why people love web programming so much. There’s always a challenge.
LOL, these examples are exactly why I got out of web programming. Thankfully I never had to deal with any of the modern frameworks. I was getting hot flashes just scrolling through this page.
I've heard this described as inherent complexity versus accidental complexity.
Inherent complexity (due to difficult real-world constraints) is fine. Accidental complexity, like that caused by overcomplicated tools or architectural decisions, just feels bad.
There is a threshold where you can still make things work right despite the accidental complexity, and some enjoy that challenge, but beyond that threshold you just have to accept that things won’t work right. CSS is very often beyond that threshold.
I appreciate things that are well laid out. I just don't get satisfaction from pixel pushing myself. It might be different if it was a small product or one I was vested I from the beginning or owned. OTOH backend implementation details I go out of my way to do at my best probably goes beyond what many others consider necessary especially when no one really sees it or may never be a practically relevant design or performance issue.
For me, personally, React makes up too many new things just with potentially slight modification and thus adding unnecessary layers of complexity. Then it is incredibly painful if you're ever in a position to debug someone else's code when they were using react. It's not as bad as having to deal with graphQL but it's still pretty awful.
Unfortunately in web programming, an inordinate amount of time is spent on concentrating on the rendering side, messing around with the CSS/CSS framework, because thats what people see, and less on understanding state flow or the backend data model. That on top of deadlines, and have a recipe for disaster. It actually took me, a seasoned programmer with 15+ years professional experience, a few weeks to understand React one-way data binding to the degree that my UI did not have severe bugs.
But when you do have a nice component hierarchy, reasonable CSS and proper data flow mechanisms, its quite nice what it can accomplish, that would not almost unfathomable with Vanilla JS.
That bright yellow background imprinted my eyes for 5 minutes, there's other way to leave an impression than fucking up with my senses, like writing a clear concise article instead of a never ending list of examples interrupted with distracting fake mouse move.
I quite like the yellow. You should try and use your brightness slider, because it is not brighter than most real world yellow (i.e. illuminated by the sun which is orders of magnitude brighter than your screen)
Unless you are adapted to live in a darkened cave, that is.
Not saying your opinion is wrong, but for some reason I found myself consciously liking the yellow a lot, which is rare for an article background color for me
I think centering in general is a difficult thing. I wanted to mount an AC indoor unit over a window. Now, do I mount it center to the wall or center to the window which slightlty offset the center of my wall? I made the call to center it based on my wall. Now, 2 out of the 5 people that have came to my room asked me about why my AC unit is off-center. For them center is relative to the window and discussing AC unit placement as a conversation starter is a good idea.
Here's my real world example that seemed to break everyone's brain...I had a room in a house that I wanted two ceiling fans installed in, in a line, with even spacing between the fans themselves and between the fans and the walls at each end.
Everyone I called over to do said work said easy peasy, measure wall to wall, divide by 3, done and done.
I tried to explain this centers the bases, but then the fans will be closer to each other than the walls, but they'd either argue or just roll their eyes.
I finally just marked the ceiling myself, and found a person to do the work without asking why or arguing. Ah, perfectly spaced fans at last.
To better understand how people might get confused... Imagine a room 9 feet <insert your favorite unit of measure> long and fans 2 feet in diameter. If you put them with bases equally spaced—3 feet apart—you get a gap 2 feet between the wall and fans… but 1 foot spaced apart in the middle.
Naively, you move each fan a half foot closer to the wall. This makes the gap 1.5 feet to the wall but now 2 feet between each other. (You might find ways to argue that this looks better visually than the true answer below, and that depends on a lot of perception-altering factors including how low the fan hangs from the ceiling, amount/ratio of space available, the distance from the non-perpendicular walls, and light sources as they might cast shadows with different sized gaps on the ceiling.)
You need to take the total room length and subtract the fan diameters, then divide that by 3. (So, 5 / 3 = 1.667 or 1'8" from wall to blade tip.) Thus, each base should be 2.667 feet from its nearest wall. This makes a gap 1'8" between each blade tip:
Bringing this around to the theme of web design, this is akin to space-between, space-around, and space-evenly in justify-content[1] (except there isn't a "space the center of each element evenly" selection, except maybe stretch or nesting everything in another flexbox)
In case the author reads this: Please respect prefers-reduced-motion for your cute mouse cursors that wander over the screen in a very distracting fashion.
While I agree, it usually seems the majority of HN does not, and sees it as promoting the boring corporate web of today instead of the creativity of MySpace/Geocities pages -.- Accessibility is often frowned upon by commenters.
A designer once advised me to align an icon with the "typographical center of gravity" - as in, of the "ink". This would make the location of an icon next to text depend on the text itself, not just the font. Obviously, we compromised in practice :)
That’s actually arguably the source of the problem in a lot of these examples. In some of them, the bad alignment would look good if the text next to it contained more descenders.
This could be compensated for, of course. For e.g. a single checkbox and text, move the text a bit lower if there are no descenders in it. But that doesn’t work if the text is user input, or if there are multiple text boxes in a list: it’s noticeable (and unpleasant) if the baselines of the text are in different places next to their individual checkboxes if - even if they’d all individually look best in that alignment viewed alone.
And if the text is editable, it’s even worse. No-one wants their text to be jumping up and down while editing to maintain optical alignment.
The problem gets even worse if you have mixed language support, and the text might be in languages with ‘tall’ characters (Thai, Arabic, sometimes Vietnamese - and a long list of others) or a different idea of ‘line height’.
Compromises must be made, unfortunately.
Of course, that doesn’t excuse a lot of the examples here, which are of specific designs - but it does mean that a lot more ‘design’ time is required, especially if there are multiple localisations, than feels at-all intuitive to anyone who has not done this.
Agreed about Vietnamese, which brings up another issue: diacritics. A word or phrase that is heavy on uppercase with diacritics ("BÁNH CUỐN") will look quite different in the vertical plane from one with a lot of descenders ("eggnog"). Even for developers who don't worry about Vietnamese, it is quite common in North America to require support for Spanish and/or French, which can also feature a lot of words with diacritics: "¿Ándale, vamos?"
Text based layouts should come back. Search "TextOS" on twitter for examples. If someone finds it, post a link below (responding on a Kindle Paperwhite, twitter won't run)
It's technically possible (although infeasible) with current web api though. You can draw texts to canvas, sample it, get the pixel value and find the true center yourself. But web also never guarantee that text on canvas is as the same as the one you see visually, so you can only find it out one by one.
You can draw a whole span or div that is invisible with fonts in it and everything off screen measure it. Delete it or then show it or move it or whatever. But I've done this before with JavaScript.
> (also don’t ask why justify-content became justify-items)
It didn't. `justify-content` works with grid too, and will bunch all the grid cells into the center. `justify-items` is if you want the contents of each grid cell to be centered.
Also, `place-content` or `place-items` for grid does both the horizontal & vertical at the same time.
I admit that CSS isn't always obvious how it works, but it seems like the author didn't care to check
I genuinely expected more of your writing and research (I’ve read your blog before) than regurgitating ChatGPT output without thorough verification and then using that as a defense when the error is brought to your attention. I expected you to understand ChatGPT cannot be blindly trusted.
This undermines trust in all technical parts of your writing.
I got fed up with a font being off-centre on a design I was trying to develop and I ended up using this descent-override CSS property on the @font-face block which works rather nicely: https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/...
That way you can control the vertical position of the whole font.
The Apple one doesn’t seem fair. You can do the math to center the box but typography with descenders throws everything off. I think if they had centered it “correctly” it would feel off.
The iOS upper right tray stuff looks right how it is, I don't think they were trying to center them vertically with each other. It's treated more like a line of text, with some parts of the icons (outer border of the battery, rounded corners of the LTE bars) dropping below baseline like descenders.
And the Business login screen pushes the centering around because it assigns different visual weight to the UI element versus its label. When the label is on the left (text fields) the centerline shifts right, and when the label is on the right (checkbox) the centerline shifts left. The elements that stand alone (building circle, Business text, Sign In button, Need help signing in text) all keep a consistent line. If you ignore that visual weight and just center them, you probably end up with it looking wrong like a triangle with its bounding box centered in a circle does.
It don't even talk about CJK though. CJK texts mixed with latin characters is also a giant source of headaches.
For example, the following characters: "jh中"
Depend on the use case, you may want the "中" to align with "j" (for a tight layout like terminal) or "h" (normal articles). But there is never a way to specify it. You just pray that it is correct or your text gets clip out in tight layouts.
If you Google “Why is CSS terrible?” you will get dozens of questions on SO or Reddit about noobs complaining about CSS and how it is outrageously hard to understand and use.
Nearly every one of those threads has at least one comment that reads like, “Well I’m a senior web developer and if you don’t like CSS it’s probably because you’re a fucking idiot!” Some will go so far as to say if you don’t like CSS and you’re a man, it’s probably because you’re a misogynist: https://youtu.be/dxY5CdZNzsk?si=BiVr0uPXKIq-T4dJ (Seriously, watch the video, it’s outrageous.)
Meanwhile, more than one web developer has communicated to me in private that they hate CSS and barely understand it after years of using it professionally to make money.
> Meanwhile, more than one web developer has communicated to me in private that they hate CSS and barely understand it after years of using it professionally to make money
They barely even understand it?? I think the biggest problem with CSS is the same problem plaguing C++ and other older languages. Cruft. If there was proper versioning and pieces of the language were deprecated in favor of modern techniques, it would remove a lot of ambiguity. Heck, if there was a built-in linter that warned you about common errors that would be a massive upgrade!
The only bad part about CSS is that there’s a dozen ways to do everything.
With that said, any developer telling you they hate it probably hasn’t worked with the “state of the art” in other UI development. Go work with WPF, UWP, QT, ImGui, JavaFX, Swing, or any of the dozens of other desktop UI frameworks. Then, try to make a moderately complex style and apply it to several elements. It’s a PITA. I too hated CSS… but then I worked with WPF and JavaFX and lots of those other frameworks: and they gave me a fresh dose of perspective.
I’ll gladly take the ability to do everything a dozen different ways over the inability to do anything that strays from the happy path in the framework I’m using.
JavaFX uses a dialect of CSS so that's not necessarily a great example. It's also somewhat simplified compared to normal CSS, for example, the way layout works is more normal for GUIs (containers that implement different constraint systems). For things like theming your UI it works pretty well.
I've done web CSS and JavaFX CSS and for app GUI I'd much rather use the latter. For nicely styled documents with good typography on the other hand, web CSS is going to be better.
JavaFX also scores points for having a binary form of CSS that can be loaded and parsed much faster.
CSS as a language is bloody awful of course. The prevalence of dialects that compile down to it is always a giveaway that the language didn't keep pace with people's needs.
I misspoke in my comment and must have used Swing more than JavaFX (I’ve used both, but forgot which one I primarily used, this was 8 or 9 years ago and a short job). Either way, I really don’t like when only a subset of the language is supported, because then it becomes a constant guessing game of whether or not something is supported. In the case of JavaFX, there are a few features not supported and a couple gotchas mentioned in their docs.
And I think vanilla CSS is not that bad. I definitely don’t think it’s bloody awful. Most wrappers around the language added variables and nesting. CSS now supports variables and I think it even supports nesting :)
There’s probably other features that could be good, but for a language that’s just meant to provide style metadata for my UI, CSS works fine.
It's not really a subset, more like a dialect. It has some features that web CSS doesn't, for instance. Some things like animations use the same ideas and APIs but there just isn't a CSS DSL for it, you code up timelines and keyframes in the host language (usually but not always Java).
The problems with CSS are more around the high levels of inconsistency, difficulty making it fast, lack of modularity and the fact that if you make a mistake either nothing happens with no error, or you get visual corruption. It's just an extremely frustrating technology to work with, especially if you only use it occasionally. Although the article talks about font metrics a lot, a big part of why centering things is so hard is thanks to CSS and its legacy which is why it opens with that. Every time I do web design I discover that the current best practice has changed, and there are dozens of new properties with similar names to existing properties which don't seem to work or can only be used in combination with other properties.
My biggest problem is that the dark mode flashlight looks bad, I can see the difference in color between the flashlight image darkness and the darkness created by the shadow, he should change the color of the box shadow from #000 to #010101 so it matches better the black of the flashlight image.
Sure, in a normal monitor it is not noticeable but in a good monitor with good blacks and HDR it is super noticeable
Just a few weeks ago we released a feature where one of the most prominent buttons had a misaligned icon. The feature was reviewed by the QA engineers, the product owner reviewed it etc. I was the first person to notice it. After I pointed it out, everyone started seeing it, too. However, I had to specifically mention that there is a misaligned icon on a certain button. People couldn't see what's wrong even when carefully looking at the button, if you just said "something's wrong with the button". I had to actually say "the icon is not centered correctly". Only then they started seeing it. I guess most people just don't care.
Funny that this doesn’t even mention the actual critical failure of CSS centering: data loss on all items overflowing to the left of the container. Items to the right can be scrolled into view, but items to the left are entirely inaccessible.
Yes, because content is almost never placed above the viewport. Do you have an example of that happening?
But I suppose the complaint might be able to be generalized to all items past the start of a main-axis centered flex-box. Doesn’t make the failure more excusable.
margin: 0 auto; (or simply auto for two-axis centering) will not have that issue. For multiple things in line, gotta use :nth-child to apply margin-left: auto on first item in row, and margin-right: auto for last item.
Finally you can allow container to grow with the contents.
Hm, that works well enough as a replacement for `center`, but not any of the `space-*` variants. But "min-width: fit-content" works nicely for all the cases I tried.
Thanks for the clarification. Still a rather horrifying effect for me given that I was trying to take in the content of the article and not the latency-ridden odd movements of other people's cursors, am I missing something (more!) here in terms of the why?
> don’t ask why you need to remember four words instead of just horizontal/vertical, it’s still better than before
The reason is "display: flex" can be a column or row. The "align-items" property describes alignment along the axis, so vertical for column and horizontal for row. The "justify-content" property is the other direction.
I wonder if something like this would've worked. I always mentally think of flex box as having a primary axis that's like a rope that runs through the container, and the children are stuck onto this rope.
```
display: flex;
// The flex axis is the axis where items get added. So horizontal would add things to the right, vertical to the bottom
flex-axis: horizontal;
flex-axis-align: center;
// Normal as used in math to mean perpendicular to the curve
flex-normal-align: center;
```
Or `flex-align: center;` for short.
This would give a decently simpler mental model with only three terms: the flex axis, the flex normal, and the alignment.
And actually it would allow some interesting natural extensions! You could do `flex-axis: path(...)` to specify an arbitrary curve to position your elements on.
Any edge cases I'm missing as to why this wouldn't work?
The other CSS terms for this are block and inline, as in padding-inline-start and padding-block-end. Whether it’s the top/bottom/left/right edge is determined by flow direction. iOS/SwiftUI calls the inline directions leading and trailing, but I’m not sure how it works with vertical type
Technically, block and inline dimensions are defined with respect to the direction of the text. The terms used in the CSS spec to refer to the direction of justify-content and align-items are the main axis and the cross axis, respectively.
Just makes me happy I'm not the only one. I always feel like I'm an idiot when I resort to setting position: relative and nudge icons a pixel or three here or there.
I’m a designer since my parents got me a copy of CorelDraw in the mid-1990s (I might even become a good one someday!), and this has always been a challenge. I’ve never jumped onto a font as quickly or as thoroughly as I did with Inter, and now I have one potential reason for why my subconscious got so piqued after my first experiences with it. I probably spend a huge proportion of time when developing websites doing dozens of CSS tweaks to correct very subtle alignment problems (whilst doing my best not to create more). Glad to see my neuroses being shared here!
~20 years ago I was building websites and I would spent hours to make things "perfectly" arranged on them. I hate it when it's not the way it was supposed to be. Pixel perfect or nothing. And then I just stopped with web and moved on with my life. It's time consuming, buggy and while it worked in one browser it didn't work in another. Screw that.
Correct. The article does a bit of a bait-and-switch by showing that centering a rectangle within another rectangle is mathematically trivial, and then going on to complain about misaligned stuff that is mainly "irregular shaped text (which can change based on translation, etc) within box with curved corners".
I'm out of the web development game, but in my day it was still quite possible to vertically center text and icons consistently. You just had to notice it was busted in the first place, and then go in and fix it. It's not a technological problem, or at least not a non-trivial one.
The problem is that, if it's off by a couple pixels, the front-end engineer may not notice it, and the designer may not even look at it. Or, if they do notice it, they think "do I want to file a bug report right now, or do I want to work on my own ticket right now?" Having worked in both roles, this is my experience anyway.
I agree that there's no consistent way to center things that always works, no matter what, without anybody thinking about it or paying really careful attention. I think we prioritize solutions with those performance characteristics, which is a separate problem of even greater magnitude.
No, this was never possible, not in web development. You could do it in one browser on one OS, but then they could be off on another browser on another OS.
It's absolutely a technological problem because pixel-perfect rendering and alignment is not part of the HTML/CSS specs, when it comes to how fonts get drawn.
The only way to actually get it perfect is to do browser and OS detection and then hand-code a bunch of manual offsets that you keep up to date. And obviously that would be insane.
> The only way to actually get it perfect is to do browser and OS detection and then hand-code a bunch of manual offsets that you keep up to date. And obviously that would be insane.
That's exactly what you do. And that's what I'm saying: the view that the product we're making is not worth doing one-off fixes for, that we need one solution for everything. No other trade has this delusion about everything being a perfect system you can control from a single commanding height (a component library, for example). Even other forms of programming, like game development, don't pretend you can avoid doing one-offs. Just web development, as far as I can tell.
So, I would use the term "pixel-perfect" to mean that the person making it can target some specific layout, choosing all aspects such as the sizes and fonts and exact colors and such. However, even without that, you can still say "I want this to be monospaced red on a blue background and larger than usual" and all of those properties can vary but hopefully something should happen that preserves at least some of that intent? The properties of vertically centering something inside of a table cell to me are not part of a pixel-perfect layout system, and yet I feel like my user agent is doing a pretty poor job if it doesn't have at least some sane strategy for this, and to the extent to which there are multiple different good ways to do it I hate that it seems to default to "if I can't select a good way I'll just use a bad way" in its zeal to refuse to expose multiple definitions of "centered" to the web developer (and again: I don't think being able to say "try to center this in a way useful for numbers" is part of "pixel perfect").
You're right. The browser should just expose this capability and get it right.
Recently I've learned that even the parts of OpenGL which are fully specified give wrong results on ubiquitous hardware+driver combos at the pixel level. The commonly proposed solution is "instead of using the transforms and blending exposed by OpenGL, do it correctly yourself in a shader." Gosh.
I mostly agree, but not entirely. The problem is that things that are lined up look nice from far away, and very close up, but not always when reading text.
The Apple "Manage" button is the simplest to illustrate. You might think that just having equal vertical space above the M and below the g is the best, but when you read text you're also used to seeing letters stick out of the bottom of the line. So having the g not protrude might look odd.
Or if you have two buttons next to each other, one "Manage" and one "Add" - what should you do? Should you centre Manage, and put the text for both on the same imaginary horizontal line? That will make "Add" look odd when viewed in isolation.
Or should you centre Add? Then Manage will look odd when screenshotted by itself.
Or should you let each have their own vertical centre? Then they will be mismatched.
You align by the space between cap-height and baseline. Always. It always looks good. Even for lowercase. You don’t need to think further. That’s it. That’s the solution
I’d have liked a bit more on the visual (and subjective part, this is probably also there the issues lies, apart from bugs) alignment aspect. The first apple example seems pretty well centered to me for example.
I’d like to use system fonts more often, but apart from the vendor brand fonts like Segoe or San Francisco they are pretty terrible to use all around.
So choosing a custom font and fitting everything around it seems like the solution for now. Apart from that, I’d like to see more support for leading-trim, which will help make things better, at least on the web. https://medium.com/microsoft-design/leading-trim-the-future-...
I agree partially, but I also noticed on some projects that not everything looks better when absolutely centered. Sometimes something is centered but looks weird. You nudge it a bit off center and looks perfect.
That's mentioned briefly in the optical compensation bit - visual center is what looks like the center, mathematical center is just the middle of the bounding box. Triangles are the obvious example, but even more annoying is logos where you have the ® or ™ at the end, which have very little weight but are included in centering math on badly cropped logos.
The post starts from "funny" statement. "It has never been simpler" and then two examples follow -- one for grid, and one for flex. Both are broken. Yes, I know, they should work and they probably were intended to work by design, however CSS design levels are so low, that centering via simply commanding "center" is not reliable. Hand up if you know when it fails (in 100% legit scenario) and how to "fix" it :-).
It's not just computer science thing. I have numerous misaligned electric sockets, doors, light fixtures etc all over my house and it drives me crazy that I can't do much about it!
One important thing is to avoid adjusting alignments between two things by offseting against a third one. Typically, offsetting both the icon and text relative to container. And less infernal approach is the align the icon relative to text (eg: use percent (or em!!) vertical align for icon to offset relative to text), and _then_ adjusting centering in container.
Ho, and take car of sub pixel when adjusting, they cumulate, and rounding will bite you !
Since flex layouts are widly addopted I seriously never run into centering issues anymore. Either vertical and horizontal alignment is very easy. Also with dynamic font sizes/lengths. I honestly see more issues in performance, since nested flex layouts can cause quite some layout passes which are not always known to the developers, but noticable on older/slower phones.
But is it really worth fixing these things? What do you achieve by spending time and money to fix these details, other than making users slightly less annoyed by your design? Maybe these details are not fixed because they don’t really matter that much. Have you ever stopped using an app because a button or icon was slightly misaligned?
I think realistically it's more of a situation of why don't they just work correctly in the first place. It's not that everyone should spend extreme amounts of efforts for perfection it's that this is one of the most basic things that should just be correct out of the box.
It doesn't give me much confidence in the company's seriousness about quality. When I see these kinds of things in applications, my mind starts thinking, "OK, I wonder what else they half-assed?" Does the main functionality really work? If they can't even notice problems that you can literally see with your eyes, what important invisible things are broken, too? Should I really fork over hard-earned money for the premium version if they can't even get basic shit right?
I dunno. I found out that people who do care about how things look like, tend not to care about how they work and whether they are practical. And the other way round too. The slightly misaligned button is not "basic shit". It is useless shit.
And this works on company level too. The groups that spend a lot of time caring about visuals tend not to give a damm about much else.
I can see the difference between practical design and bad design. A misaligned button is usually the latter.
Those who just want the thing to work without much regard for the looks of it will tend to use whatever default their UI package comes with, with minimal styling, if at all. It is often not bad in terms of correctness. Defaults may not look great, but they are usually well designed and consistent.
If you have alignment problems, it is often because you tried to do something to the looks, but did it poorly.
I did not mean it as in difference between "practical design and bad design". I do agree there is usually tension between the two.
Simply, people who care about function wont notice misaligned button. And people who are notice misaligned button usually prioritize visual stuff over everything. That extends to managers and whole companies.
Pretty much no UI package will have everything aligned out of the box, it is not even possible. When you use them out of the box without tweaking, you either get misaligned things.
> Have you ever stopped using an app because a button or icon was slightly misaligned?
Maybe, maybe not, maybe it made me not use the app in the first place.
It is one of these little things that make the app look unprofessional. I have been a bit uncomfortable using banking apps with misaligned icons. It the designers can get away with misaligned icons, what can the core developers get away with? If a company is sloppy with their design, maybe they are sloppy with their security too.
People can easily see these visual details, they can't see the back-end but for the lack of information, they will assume it is made with the same care, that is, not much. And maybe they are right.
I think it comes down to which type of market you’re in. In some markets, like highly congested markets, design makes a big difference. It can be less important in more niche markets
Totally agree - I think that all the examples included in the article (including high-profile software from wealthy vendors) just show it's not THAT important to have everything pixel perfect aligned and meticulously crafted, it needs to be usable and somewhat good looking and that's enough.
This article makes it clear to me just how different perception is in different people. How much or how little this errors scream at you in your mind. If everyone was as sensitive as the author (I am close), then way less errors would be left there, since so many people would get annoyed by them.
This accidentally highlights yet another problem with icon fonts.
Terminal-based browsers with image capabilities, e.g. w3m, can display image-based icons. Fonts on the other hand are (usually) unchangeable on terminal emulators. So if you use icon fonts, it will look like garbage on terminal browsers, but with images there is a chance that it will work.
Sure, who cares, nobody targets w3m in 2024. But the problem can surface for people using modern browsers too, if they explicitly override your font for accessibility reasons. (For example, there exist fonts designed to aid dyslexic readers.)
Then on (relatively) well-behaved sites they will see only a text description; on others they will just see some empty squares.
I think the font metric image has an error, it labels the descender position as -500 but the text says -275 and looking at the other numbers in the image that seems about right. This left me confused for a bit while trying to follow the calculations.
I gave up trying to center fonts and icons in every situation. I can't explain to my boss that I need 3 days to center a fucking button, especially when he doesn't even notice the problem to begin with.
Which is a bit sad imo. There is a place for both competencies within most organizations I feel. But as JS has taken over more and more of the frontend, suddenly you need to have a masters degree in astrophysics to build a website and those with more of an eye for design and details get pushed out or become disillusioned and go somewhere else, leaving the app/website in an even worse state now that there is nobody left to give a damn.
This partly happens because scaling of one vector is independent of another vector in different coordinate systems. The vector outside can scale but align with parent than the child inside.
There are only two hard things in Computer Science: cache invalidation and naming things.
~~~~~~~~~~
Let’s analyse how the joke words.
A quick warning though -
Explaining a joke is like dissecting a frog. You understand it better but the frog dies in the process.
- E.B. White
First the Setup —
“There are only two hard things in Computer Science:“
We’ve established there are two things and they are hard, and they belong to computer science. This immediately begins to establish an expectation of technically difficult topics.
“Cache invalidation” is the first example and this is a pair of words that look technical and difficult, even if you don’t know what they are.
This completely reinforces the expectation that the next thing will be even more bewildering.
Punchline:
“And naming things.”
In the third part of the joke - we subvert expectations. “Naming things” is a very down to earth concept, anyone can immediately understand. And anyone can readily appreciate the truthiness — naming things is hard.
This subverted expectation is what makes it a joke.
If the two things were listed in the opposite order, it would still be true and still be insightful - but it wouldn’t be a joke.
The popular addition:
“And off-by-one errors” works even though it is “putting a hat on a hat” because the very first expectation was
“Two things”
… and now we’ve subverted that expectation. And in a paradoxical manner we’ve retained the truthiness present in the first two examples.
So the short answer is - don’t start with the punchline.
Yes CSS is hard, yes declaratively anticipating all the various types of media you may display on and their relative interaction is a nightmare of variables. BUT, that is enough to justify the inversion from using declarative markup to actually writing some procedural code. Write a function to measure the screen, measure the elements on it, and adjust them dynamically at runtime.
No, that's just in web development. Otherwise things are pretty trivial to keep centered. HTML/CSS somehow dropped the ball so hard, it became lobsided and will never center itself correctly.
I mean this just proves yet again that CSS is a convoluted mess not suited to use as a styling language. Its only merits are that it has been around for a long time and all browser support it.
I'd much rather use a proper grid layout with subgrids and local/global co-ords same as game dev and in fact I've always wondered if I can just write a web lib that uses webgl to render the page instead. Problem is DOM engines are just too efficient compared to recreating it all myself in js/webgl.
I'm pretty sure you can narrow that down to
"icons. the harde..".
I'm not sure that quitting icon fonts is the answer. When you try you pretty quickly remember why they exist
Maybe I'm just an awful person but one of my little pleasures in life is deliberately leaving things slightly misaligned or mismatched in colors whenever I can. I don't care about it myself so it's fun watching people caring too much around me.
TLDR; understanding the math of centering stuff doesn't mean you know how to center stuff in design.
The visual/optical center is not the geometric center. It is slightly above.
Graphic design basics.
The author mentions the word 'optical' once and 'visual' twice. Never in the above context.
I.e. they never explain this, so we must assume they don't know about it.
And we actually have evidence they don't.
The image below the sentence "Apple can't do it" is an example of visually/optically correctly centered text on the vertical axis.
Slightly above geometric and giving the lowercase letters more weight in the decision. Some designers would argue the text should be moved down one pixel in the example at hand but I'd disagree.
The problem here is a different one. The ellipsis (...) is very light, optically, so the horizontal center should account for that and the text moved slightly right.
That is not shown or talked about at all. Go figure ...
Yes, there is a problem, it's the enshittification of design everywhere.
Centering not existing is part of it.
As are people like the author who understand the problem but lack knowledge (sea above) to detail a correct solution.
They say "we developers" in one sentence. Graphic design was something you studied at uni when I was young. Just as CS. Maybe I'm just old but you don't know shit about centering stuff in design if you know how to center stuff mathematically.
And yeah, since I'm ranting:
Don't get me started on Material design. Where to start?
Tiny text only buttons that don't even have an outline and whose size depends solely on the length of the text inside. Etc.
Is the author here? Can you give us a toggle so we can turn off the moving cursors? It's a little distracting. Reader mode isn't working so well, so I deleted the element in developer tools in the mean time.
I thought it was hilarious and delightful, it made me smile and feel at home. But I certainly understand why others would hate it and not be able to focus on the content.
You're being downvoted, but here's an upvote from someone who also found this annoying. Confusing at first, then annoying once I saw what was happening.
First time probably ever that I've had to disable Javascript because of the creepy and distracting mouse thing. It really feels like you're invading other people's privacy, and if it doesn't, having things randomly move across your field of vision makes it difficult to read.
Tonsky's website is infamous for making a mockery out of modern UX. That's also why toggling dark mode turns your pointer into a flashlight. I agree the mouses are distracting and I always use reader mode when browsing his site.
I had to open up devtools to be sure, but yeah, there's a websocket that constantly streams your cursor position up to the server and constantly streams everyone else's cursor positions down to you for rendering.
As someone who compulsively scrolls, selects and fidgets while reading, it actually made me quite self conscious to realize that other people would be distracted by my all-over-the-place mouse movements.
(It is a good article!)
- Install flooring
- Install trim in your own home
- Build / install cabinets
You will now see:
- Odd flooring patterns and uneven floors
- Know what it looks like when trim isn't coped
- Uneven gaps between doors
Then you have things like flooring, installing windows, and anything on outside, however, where I’ll absolutely make sure it’s perfectly everything. Basically so my floors have none of the issues you describe as an example. Part of the success behind this is to hide the imperfections. You’re not going to ever build a perfect floor if you build it all the way to the wall. So what you do is that you leave a gap between the wall and the floor and you cover that gap up with wooden “footlists” (again not sure if that’s the correct English description). This gives you a “perfect” floor which aligns with everything in the room. The more crooked a room is, the more you have to cheat, but if you put in the effort it’s almost always achievable.I would like the small imperfections in these things as well. Ok, maybe not on the outside unless I was very sure it wouldn’t have an impact on the integrity of weather protection, but I wouldn’t mind crooked floors. The reason I strive to make them perfect is that other people won’t, which will make a property much harder to sell. Because unlike imperfect ”walling”, a floor correction/replacement will absolutely impact the value of a property.
But then there is the part where you will absolutely notice it when it’s not installed correctly. Which is what I guess you’re getting at, and I agree with you. The thing with buildings, however, is that you have to cheat. Buildings are imperfect and they can even more around a bit as weather conditions change. So with buildings you have to cheat. Which is different than with aligning things on the web, or at least it should be. So this is the part I disagree with a little.
As a side note people shouldn’t accept crooked floors and so on, especially not when you’ve hired professionals. They should know how to cheat.
Here in the US, it's called “baseboard”:
https://www.google.com/images?q=baseboard
https://en.wikipedia.org/wiki/Baseboard
“[Baseboard's] purpose is to cover the joint between the wall surface and the floor. It covers the uneven edge of flooring next to the wall; protects the wall from kicks, abrasion, and furniture; and can serve as a decorative molding.”
So much of what happens in house construction is about water management and without understanding it, it’s common for people to create issues. Regularly see patios that cover airbricks, causing suspended timber floors to rot.
"Spartle" = Spachteln? You may trowel your wall (with a trowel full of plaster). At least that's what I do here in Canada.
"Footlist" = Fussleiste? Leiste is not a list. Leiste translated can literally just be "trim" and "foot trim" is quite close - leave out foot and you have what it's actually called. Floor trim, baseboard, baseboard trim (to distinguish from 'baseboard' just meaning 'baseboard heating' if context isn't clear etc).
I think your parent, like you are saying in the end as well, was also less worried about seeing your own imperfections (tho that's of course a thing too) and more in line with the original comment about "not being able to unsee it" in general.
And that is definitely true. You see all the badly hidden imperfections from professionals. And you will also see all the well hidden ones but you still know they're there now while before you did it yourself, you never even noticed. It can also make your relationship with professionals worse because you will see the hiding but have trouble distinguishing the correct line between "well hidden but visible to the professional eye" and "bad job" :)
The word for this is wabi-sabi.
design systems are imperfect, and can become even more so with changing specs/frameworks/dependencies/browser updates/...
I’m curious if other people detect interrupted or irregular patterns so readily. It’s like there’s a part of my brain just looking for anomalies and I can’t turn it off.
It feels like walking through a maze, with an uneven floor and bad lighting, full of dead-ends, compared to walking down a pleasant, well-lit corridor.
My main concern is the writing I see coming out of the Public Relations and Communications departments. Writing is not exactly tangential to those fields.
It wasn't always this way. What has happened?
I suspect it’s all connected to the rise of a professional management class, rather than promotion through the ranks, and management by people who’ve done the work. Nobody who’s in a position to demand better or to make sure the right people are in the right roles, actually knows WTF they’re doing outside of a spreadsheet and PowerPoint.
I am observing a lot of people in high paying jobs who don't have a clue how to do even the basics of their job (like being able to type proficiently in a job that requires written documentation).
Is your shift key... broken? No? Use it please.
“Have you taken the dog out?”
“Yes”
Vs
“Have you taken the dog out?”
“Yes.”
The second comes across as the responder being potentially irritated at the asker. I believe that this comes down to the amount of effort required to type the reply; adding a period is making the explicit choice to do so, whereas not doing so is the default. This isn’t the case for sentences in the middle of a multi-sentence answer, since a separator is needed anyways. But I find myself not adding a period even at the end of multi-sentence messages, and I automatically read any message ending with a period with a different tone than one which does not.
Maybe I’m just nuts though, that’s always an option. But with text being such a relatively limited medium for conveying emotion in short messages, I think this is a reasonable solution.
(1) My phone absolutely tried to correct that back to "grocer's"
I think you're missing the joke of the name!
So "the grocer's apostrophe" makes sense as a phrase referring to a typical individual grocer with a typical atypical apostrophe, standing in as a representative for all grocers and all their darned grocers' apostrophes.
Most people are able to naturally filter out most of it. You’re just a little less equipped to. People with ADHD have similar problems.
Psychedelics remove most of those filters, causing someone’s brain to get the raw data including all the anomalies in the processing, which makes patterns (visual and mental) both suddenly much more apparent and do weird things :)
All the time, and I learned to not care a lot, even like some; for instance there's a lot of (mostly abstract, surrealism) art which does all the things wrong on that front but which is extremely enjoyable to me. Same weird way with music: exact 4/4 stuff is mostly boring, often even annoying, but give me funky off-beat stuff, chaos and noise and it brings a smile to my face.
There's only one thing which I can't shake off and that's lines which are meant to be, but aren't eaxcatly, parallel or right angles. Can keep staring at those. Especially when they are like very close to being correct but look like they're off (for like 1mm over 1m). Not the first time I actually get up and take a ruler to verify.
Like one part of the article shows the Apple logo in a circle, and the correct centering is not to have all points on the logo equidistant from the circle, but to allow the leaf to go a lot closer than the rest.
Very much in line with being neurodivergent.
Sounds more like autism than ADHD, but it's hard for me to tell, 'cause I'm both[1].
[1] https://romankogan.net/adhd
I was about to write: As someone late-diagnosed[1] with ADHD[2] and discovering they're autistic, ... -
>Once I was diagnosed with autism, this tendency of mine made a lot more sense.
...yup. This is what I was a about to write.
>I’m curious if other people detect interrupted or irregular patterns so readily. It’s like there’s a part of my brain just looking for anomalies and I can’t turn it off.
The answers to that are no and yes, that's the blessing and the curse of autism.
Seeking and recognizing patterns is one of the defining traits.
_____
[1] https://romankogan.net/adhd#Diagnosis
[2] https://romankogan.net/adhd/#Awfully%20Described%20Human%20D...
/rant
Does anyone else who comes into the house notice anything? Very unlikely unless they are craftspeople.
What greeted me was an uneven landscape of tiles that the naked eye just didn't see.
That laser level actually revealed plenty of places around the apartment I dare not look at anymore, lest I get annoyed at the contractors... and the original builders of the block.
I just patched a whole bunch of drywall cutouts after having some electrical work done. Now I when I look at a new construction house, I can tell which builders use go cheap on drywall, esp. when there's too much texture.
Then you have the same scenario but top to bottom.
[0] https://tilelayoutwizard.com/
A few suggestions for your tool. Add millimeters as an option. I'm using 12"x24" tile for the floor but they're really 300mm x 600mm. I learned most 12"x24" are that size. Another thing I learned is with that size it's recommended to use a 33% offset pattern. This guy explains it well https://www.diytileguy.com/12x24-tile/
But I stopped noticing these things, maybe because mobile UIs are a lot worse -- not in visual design, but in that they always do weird things and live their own life.
Misalignment is a tiny dirty spot on a clean but wrecked car.
I went to an MLS game with someone who had been a soccer ref and he pointed out that the line on the side of the field wasn't perfectly straight.
(The original design had it centered in the flag; some committee later decided it should be centered in the "flag plus flagpole".)
edit: ahh.. a vote for bad kerning. lol
That's not good or bad design, it's totally subjective. Stupid website IMO
relatively . Till you take things into your own hands and fix that pesky button with extra padding on top. Huh how hard was that! Lazy devs.
You just entered the mystical world of undocumented browser behavior where every browser does its own thing. The button looks ok on chrome, but safari's borders are more round making that look still off. You won't back down, and take on this challenge, make it look great on chrome and safari too. Yay! Worth the 2 hours eh.
Up rears the monster of responsive design... it doesn't work well on safari on the phones now. Well it works for me you say, till you rotate your screen and the button is Gone !
You finally succumb and say screw it, i'll just stick with html and get back to scrolling hn.
I was in school, sitting in study hall with a friend.
He leaned over and said "Doesn't the buzzing of those lights bother you?"
and then I noticed the whining sound of the room's overhead lights and I couldn't unhear it from that point on.
bleh.
Literally cannot win.
Use precise measurements for your margins? Someone will say that perceptually it’s not symmetrical, and rightfully point out that perceived symmetry is the only one that matters. Adjust visually for your hanging punctuation, ascenders and descenders? Someone will draw a bunch of red lines and complain it’s not perfectly aligned with baseline, x-height, or whatever they prefer.
GUIs around us are rich with obviously broken examples where spinners spin out of their centers, text in boxes is misaligned, etc. However, as articles like this one show, even if every one of those is dealt with, us designers will still have everything to complain about. (Pro tip: if you struggle to find something to complain about in the English version of a GUI, just switch to, say, Arabic.)
I guess one could devise algorithms for that, but I haven't seen one that does a better job than my brain and my eyes.
That was my naive understanding for probably my first year at the uni. It got cleared up fairly quickly.
I imagine there can be typesetting/layout styles where this holds, but I would classify them as niche (maybe brutalism or something like that).
Funnily enough, in the very first example under Fonts I thought the author didn’t like “Manage…” because it could be pushed slightly to the right (due to ellipsis), but it turns out to be about vertical alignment which I didn’t see anything obviously wrong about in that particular case.
Once you deal with the obvious cases of lopsidedness in your design, the important quality becomes simply: stay consistent. Here, no self-respecting designer would pull one random example and say it’s wrong—you have to assess in context of design model as a whole, where you can either 1) show how one particular button breaks the model, or 2) argue that the model is wrong (which can be done, but good luck).
Icons can be less ambiguous, but still it depends on the shape and white space within one and the interplay with text label.
I think it all depends on your vision and its consistency.
I know the newer TeX engines, for example, support microtypographical corrections.
2D and 3D tools get this right. CAD programs, game engines, and animation programs are all far better at positioning things. They have far better layout engines and constraint systems. This is really a constraint problem. Autodesk Inventor and Fusion 360 have good 2D constraint solvers, ones that can put something on a centerline, or parallel, or whatever, including curve tools. Webland never got that far.
In the same way that one would float a figure to the left or right of lines of a paragraph, `float: left;` and `float: right;` allowed you to do the same.
Open a textbook and look at lines of a paragraph flowing (where content "flow" layout comes from) around a figure, such as an image or a diagram.
The World Wide Web was documents.
In this context, `float` was a genius idea. There's literally no other way in CSS to do this without a bunch of hacks.
I think anyone ever trying to write a paper or book with images in it using tools like LaTeX knows how bad it is to let the tool position images for you. It's always wrong, and one of the first things you learn is how to pin the image in between the text lines/paragraphs you wanted it to be between.
Text-to-diagram tools like PlantUML (and arguably even Graphviz) make this mistake too. The moment you put more than a couple things in your diagram, you discover that auto-layout can't ever make the result readable, and you look for ways to pin parts of the diagram relative to other parts; something these tools don't let you do either.
And then all three classes of tools here - HTML, typesetting, diagramming - violate the principle of least surprise in the nastiest of way: make one little change, add a letter or word somewhere, suddenly the result looks nothing like it was before, as the auto-layouting flips everything around.
Successful systems like Tom Sawyer Software or yWorks have dynamic or incremental layout features. The market of course strongly rewarded work on interactive systems like Visio that were well integrated into larger platforms.
Not sure who remembers but high performance incremental constraint-based layout was one of the computer science lights that failed in the 1980s and 90s but with so many fundamental advances in technology (processors, algorithms, solvers, software platforms) and new emphasis on language-based approaches (in part due to LLMs) there might be a better opportunity now.
Anyway it's a hard problem, it's not as if nobody was aware of it.
The problem is the people who designed CSS had an ideological axe to grind. They believed that HTML should only be used for document layout.
It was a hack but it worked better to serve the needs of the users.
Assuming you get said permission some weeks later, now hand over double-digit percentages of your top-line revenue to these despicable rent-seekers, do the same with your tax payments and notice how you're left with less than 30% of the value you have created.
https://hypercard.org
Float and clear was grandfathered into CSS since they were added to HTML by Netscape. They are fine for their intended purpose: placing images in a text and have the text flow around.
Other positioning systems you mention does not solve the same problem as CSS. CSS has to support viewports of any size and dimensions and allow text to scale independently of the viewport size and still remain readable.
Not a myth in any way shape or form. Tables for layout (not tables in general) were discouraged with various arguments in favor of "float/clear", even decades before a sane substitute (grid/flex) was available.
>Other positioning systems you mention does not solve the same problem as CSS. CSS has to support viewports of any size and dimensions and allow text to scale independently of the viewport size and still remain readable.
None of those requirements is unique to CSS, and none of those requirements necessitates the stupid float/clear mechanisms that were shoved into people's throats for 15 years.
We're talking about the style language that had layout shoe-horned into it, and which tool decades to develop the most basic layout mechanisms available in GUIs for decades, grid layout and flex layout. And even when it did, it didn't it badly.
Table markup was discouraged. There’s nothing intrinsically wrong with display:table from a CSS/semantic markup evangelist’s point of view, it’s just awkward to use, requires you to arrange and order your markup just so (sometimes contrary to semantics), and was rarely mentioned in the days of float/clear because IE screwed it up in various ways (that were more difficult to fix than those for floats). It works reliably now, but as far as laying out the page goes the requirements for ordering the markup will probably be incompatible between desktop and mobile. For insides of buttons and such, though, go nuts.
CSS, as in "CSS evangelists", influential web designers, guidelines in web development resources, books, and so on, recommended and advocated for the use of clear/float.
You might not have been there, but float layout was a big thing back then, and everybody was guilt-pressured to use that - neither tables, nor "display: table" (which was used by some, but also discouraged).
The problem is people forget context. The advice “dont use tables <in this specific context under these specific constraints>” is remembered as “tables are bad, never use tables or anything which remotely looks like a table”.
Of course for your personal Tranformers fan site you can use html tables to your hearts desire. Nobody is likely to complain.
But most web-design focused media is targeted professionals for whom it is a necesssary skill to be able to design pages which look good for most users and is accessible. During the dark age of IE6 it was necessary for developers to know and use a large array of hacks (including the abuse of floats) to achive this.
What, no? I did a lot of web development in those days and read a lot of blogs. You just needed to filter out anyone who was obviously over-opinionated and lacked any nuance. Most pragmatic people used tables and didn't feel guilty about it. If you delivered working software with a decent UX, why on earth would you care what some shouty internet person said??
So it it not really about vague “guilt-pressure”, it is just that many web developers had to follow WCAG as part of their job.
This would be pretty confusing if the table was just used to create a margin and most cells only contained spacer gifs. Especially with deeply nested tables (as was the fashion at the time) it could be pretty confusing.
Today you can just add an ARIA-hint indicating a html table is used purely for layout and a screen reader can then treat it just as divs. But this did not exist at the time.
Of course the WCAG just assumed it was not a big deal to avoid tables for layout since CSS2 supported tabular layout through pure CSS. But the reality of a web dominated by IE6 made this a much larger problem.
Nearly all layouts people actually want are table-like, and I think CSS really was misguided in its text-flow as layout approach.
I think this is the core misunderstanding in this discussion. CSS 2 supported both text-flow and tabular layout and both layout models were reverse-ingeneered from how Netscape rendered HTML.
There is this weird idea that CSS is somehow opposed to tables or tabular layout, while a significant part of CSS2 is actually the codification of how tables render.
There shouldn't be any semantic basis needed.
HTML is not a semantic data exchange format, was not designed to be (the pathetic handful of semantic HTML5 tags added to be used ad-hoc included), and it inevitably includes content, style, and behavior (js).
The semantics should belong to data intergchanged (and storage format), and the reusability should be on the data storage/query backend, not to the markup language.
Adding semantics to the markup duplicates the semantics already present in your DB or JSON API scheme or query server/storage in general.
Floats was never intended for that purpose though, it was just a desperate hack to get around IE limitations.
But html tables was not a viable alternative for organizations which was required to have accessible websites.
(Today I believe it is possible to create accissible html tables through ARIA hints, but that was not an option at the time.)
CSS allowed layouts like this to be done without tables. It still supported tables, but for the case when you actually want to show tabular data which would appear like a table on the page.
Semantics in the context of CSS is a stupid idea web designers came up with. They heard the concept of "semantic", and had to fit it in, to appear smart. Should have asked actual developers.
(the so-called "semantic web" was another such failed idea dragged on for an eternity for research grands. Remember RDF? What fun!)
The semantics is not the job for HTML, which is the final artifact for display, and not a data interchange format, nor the format you store your info as. So there's no need for it to be semantically clean and "parsable/reusable" (to do what? web-scrap it? As for screen-readers, there are official metadata annotations for those - not to mention they wouldn't know to do anything special for each ad-hoc different "semantic" tag soup people come up with with the severely limited for that reason HTML5 tags, or worse divs).
The semantics belong to whatever backend and metadata you have your content in, before it gets rendered as HTML.
And if you need to also give it to users in parsable/reusable form, allow them to query a JSON (or structured) version.
If they really wanted semantics you would think there would be actual support for that.
By the way, I've asked this question here some other day, but nobody has any idea if most "semantic" tags are being used for anything at all (and Wordpress naturally uses all of them wrong, so there is no point even bothering).
No point making a semantic web browser before we get a semantic WYSIWYM HTML editor. Maybe those could be the same program, like in olden times?
I'm not the most current, but as I remember in CSS tables those table-internal elements generate the needed anonymous boxes of rows, tbodys and such, when those arent't specified:
https://drafts.csswg.org/css-display/#example-d11b97c3
HTML is a graphics rendering language in denial about its true nature.
Grid took a long time because everything takes a long time when you have to align mutually competing organizations and there's no profit motive involved with the actual work itself. There's no real technical benefits to CSS layout over table tags. A table tag isn't a heavy object. CSS cascade calculations on the other hand ...
It's true you won't ever have a perfect semantic representation of a page (and I have no idea how blind people manage those infinite scroller), but in my mind having <nav> or <div role="nav"> instead of <div class="my_non_standard_nav_classname"> still helps a lot on that aspect.
Screen readers / accessibility tools don't use the semantic web. The semantic web doesn't exist, it refers to the Tim Berners-Lee vision of documents being XML or RDF data structures with schemas, transformed into pixels using stylesheets and XSL:T. It never happened for various reasons.
Frameset is deprecated in HTML5, but your index page can be of the older frameset DOCTYPE and each frame valid HTML5 page with a <!DOCTYPE html> declaration. This is why frames (and iframes) are actually great because you can mix old an new.
e.g main.htmlBut looking at MDN it seems you are correct, all mainstream browsers still support framsets.
If your layout is intended to be a table, then a table (styled with CSS) is the way to go, otherwise use semantic HTML (styled with CSS) and you will (in theory) have an easier time making the design work well at different sizes/resolutions and in alternate UAs like screen readers.
It's the same today though - half of HN is utterly convinced rebellious technologies like HTMX are going to save us from the evil of front-end libraries. People adopt guides or entire technologies without ever actually building something significant with them.
CSS is “the right way” to control styling and layout, but that does not mean you can’t use tables.
In the early days of the web people used the BLOCKQUOTE element to create margins since this was the only way. When CSS arrived, it became “the right way” to create margins - but that does not mean you can’t use blockquotes! You just need to distinguish beteen the semantics of a quote and the layou effect of margins.
But I’m sure someone understod this to mean that quoting things were bad.
And then it spiraled into general "separation of content and presentation" nonsense that, like in any good cult, people believed with their whole hearts, preached to make new converts, then did the opposite because reality demanded it, and couldn't see the problem. CSS Zen Garden notwithstanding, we ended up with div soups (later, semantic div-equivalent soups) inseparable from complex CSS, because form is function; your content is always designed with a particular form in mind.
See for example WebAIM https://webaim.org/techniques/tables/: “It is sometimes suggested, even by some accessibility advocates, that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues.”
The semantic web was born from a belief that it would enable a peer to peer web that never materialized. Accessibility was better solved by aria annotations a long time ago and the semantic web was never going to properly solve it.
Approximately. Like it did and does.
The simplest way is to just strip the markup (or, for purposes of indexing, just ignore any token that resembles a HTML tag). That'll easily get you 90% there. You'll lose important information that's tied to form, but that's a consequence of operating in plaintext land. If doing this to build an index of the web, you'll have problem with scoundrels stuffing irrelevant text made invisible to humans by markup/CSS/JS, but that's exactly the problem Google used to have for a long time, and the essence of what SEO is :).
It was a much saner, simpler, and more efficient mechanism that the clear/float monstrocities imposed upon people in the period before grid, which reinvented the same thing (table layout) just without the actual tags.
Grid is newer and more powerful.
Like many things in CSS features that should have been present in the original 2.0, when it became clear that the web wanted to be laid out like a magazine, Took multiple decades to actually appear. As a result we are still seeing the fallout of those failures in our ecosystem.
That is like saying Go is not a viable programming language because someone might confuse it with GOTO and consider it harmful.
They shouldn't had mean, they should had said that.
Because 99% of time we have a bunch of <p> in assortments of <div> representing a tabular data. Dozens of "web" "front-end" "frameworks" doesn't help it in any way, too.
(which, unfortunately, is why is has terrible zoom support)
Also, I often use 'zoom text only' in Firefox... that causes havoc on some sites. Also, I disable web site fonts by default.
Except for (vector) graphics design, desktop publishing, page layout designing and reporting software... The reason is of course that most printed items are unica and non-variable, but proper parametric and constraint-based would definitely be useful in report generation and signage where print formats vary or where designs need to be automatically adjusted based on texts and other content varying in size/length.
Why? Because it was designed for creating apps, not documents. HTML is great for creating documents, most of the examples in the post are not documents.
With CSS it wasn’t dumping problem on the others, it was giving the freedom. Problem with freedom is that it is never free and you also have to fix additional problems that come with it.
But that was an issue of philosophy that got trumped by practical needs.
However, nowadays we have css grids with template areas. So we can just write our HTML semantically correct as if it was more or less just about the content (as it should be IMHO) and still move things around using CSS depending on the type of device, size of screen, media used.
So the holy grail in my opinion is to write HTML that contains only content and metadata and next to no elements or attributes that are needed purely for semantically irrelevant layout and styling purposes — and then do all the layout and styling in CSS. Styling tags like <em> or the occasional <section class="notice"> are okay, one should never be too strict with such ideals.
The advantage here is that this provides the maximum decoupling between the content and the layout/styling which not only helps with future layout updates, but improves the accessability of the page.
I think the real problem is that it doesn't permit responsive layouts for different screen sizes and orientations.
Also very real issues like accessibility.
https://www.w3schools.com/htmL/html_images_imagemap.asp
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
I've seriously considered doing websites in pdf too but still have to run into a situation dramatic enough for it to be worth it. Now that I think about it again "installing" a pdf on a pc could cover a lot of app like functionality. Most important is to make it as convenient as possible to remember your business exists and interact with it.
http://fpdf.org/en/script/ex95.pdf
Although, honestly, how hard would it be for Chrome to support some new language called Super Text Markup Language that is designed for modern use with support for templating, portals, actual semantic layouts that don't rely on position on the code, etc.? Perhaps it's time.
"Google Web". Like what Google did to USENET. First they connected to USENET. Then they called it "Google Groups". Gradually, free USENET declined, and now, there is only Google Groups.
It would be so much more convenient. No more need for hosting providers, domain services, and most of AWS. Just host on Google Web.
I guess it's way more complex than HTML rendering already is
yes. IIRC Cassowary constraint solving was proposed in 1999. It was dismissed because they thought it would be too costly on the hardware of the time.
Also, Fusion 360 is now known as just Fusion (it's cleaner that way?)
What design tools express in UI/UX interaction, CSS must express in context-free grammar. It's every bit as awkward as replacing verbs with nouns.
But I'll add two more wrinkles that the author doesn't mention:
First, that font rendering isn't just about metrics but varies across operating systems and browsers. So even if you center perfectly on Chrome on your Mac, it may very well be off on Firefox on Windows.
And second, that the author's proposed solutions only work for Western-style fonts that have ascenders and descenders. It gets even trickier when you consider a range of totally different scripts from Asia etc.
We need sane font rendering in browsers that treat things like alignment in a way that we’d expect for the 99% case. If I say “center” it should just fucking center.
Why would it looks bad elsewhere?
> All websites should use the system font for body text.
Wait what? There are very different requirements when it comes to reading system widgets and actual text! (like we don't use the same kind font for code and prose).
Now disabling custom fonts altogether makes sense of you are trying yo save bandwidth, but then you aren't mad if things don't properly align.
And if you're really targeting people that have trouble loading such a font file, then you have much, much bigger problems than centering things (you basically cannot put any image on your website).
Where's that ratio coming from? Shipping fonts is just good practice when you want your website to look consistently on all platform, it doesn't mean anything else about how the website is made.
Also, 100kbps is a very slow connection, it's 2 orders of magnitude less than the 10Mbps you talked about earlier, and when you have this kind of very poor connection everything is kind of slow anyway (even the very barebone HN's front page is 120kb!).
This is in parts, however, due to font metrics, because Windows and Mac use different conventions of how font metrics are specified in fonts: https://www.williamrchase.com/writing/2019-11-10-font-height... In other words, the usual font formats don’t specify font metrics in an unambiguous way.
LOL, these examples are exactly why I got out of web programming. Thankfully I never had to deal with any of the modern frameworks. I was getting hot flashes just scrolling through this page.
You will want to make sure you work on things that are challenging for the right reasons.
Inherent complexity (due to difficult real-world constraints) is fine. Accidental complexity, like that caused by overcomplicated tools or architectural decisions, just feels bad.
I used to have that attitude, but after trying the latest version of ReactJS I think its pretty nifty for what its intention is.
But when you do have a nice component hierarchy, reasonable CSS and proper data flow mechanisms, its quite nice what it can accomplish, that would not almost unfathomable with Vanilla JS.
An horrible web experience through and through.
Unless you are adapted to live in a darkened cave, that is.
The mouse pointers are a prime example of "just because you can, doesn't mean you should".
These are multiplayer cursors. You're seeing other people using the website
I know I've read many of his posts over the last year because of that mustard yellow background. It's a strong branding choice.
Everyone I called over to do said work said easy peasy, measure wall to wall, divide by 3, done and done.
I tried to explain this centers the bases, but then the fans will be closer to each other than the walls, but they'd either argue or just roll their eyes.
I finally just marked the ceiling myself, and found a person to do the work without asking why or arguing. Ah, perfectly spaced fans at last.
Naively, you move each fan a half foot closer to the wall. This makes the gap 1.5 feet to the wall but now 2 feet between each other. (You might find ways to argue that this looks better visually than the true answer below, and that depends on a lot of perception-altering factors including how low the fan hangs from the ceiling, amount/ratio of space available, the distance from the non-perpendicular walls, and light sources as they might cast shadows with different sized gaps on the ceiling.)
You need to take the total room length and subtract the fan diameters, then divide that by 3. (So, 5 / 3 = 1.667 or 1'8" from wall to blade tip.) Thus, each base should be 2.667 feet from its nearest wall. This makes a gap 1'8" between each blade tip:
20" space, 24" blades, 20" space, 24" blades, 20" space = 108" (9 ft) room length
Bringing this around to the theme of web design, this is akin to space-between, space-around, and space-evenly in justify-content[1] (except there isn't a "space the center of each element evenly" selection, except maybe stretch or nesting everything in another flexbox)
[1] https://css-tricks.com/snippets/css/a-guide-to-flexbox/#aa-j...
In the meantime, as a fix for others, in uBo add
tonsky.me##.pointers
BTW: the movement of the small cursors is streamed live from the server, I think it represents the current mouse position from other readers.
I’m surprised ‘text-box-trim’ wasn’t mentioned.
It’s a CSS attribute that solves this on the web.
https://caniuse.com/css-text-box-trim
If only browsers would support it.
Until then, here’s a JS alternative.
https://seek-oss.github.io/capsize/
This could be compensated for, of course. For e.g. a single checkbox and text, move the text a bit lower if there are no descenders in it. But that doesn’t work if the text is user input, or if there are multiple text boxes in a list: it’s noticeable (and unpleasant) if the baselines of the text are in different places next to their individual checkboxes if - even if they’d all individually look best in that alignment viewed alone.
And if the text is editable, it’s even worse. No-one wants their text to be jumping up and down while editing to maintain optical alignment.
The problem gets even worse if you have mixed language support, and the text might be in languages with ‘tall’ characters (Thai, Arabic, sometimes Vietnamese - and a long list of others) or a different idea of ‘line height’.
Compromises must be made, unfortunately.
Of course, that doesn’t excuse a lot of the examples here, which are of specific designs - but it does mean that a lot more ‘design’ time is required, especially if there are multiple localisations, than feels at-all intuitive to anyone who has not done this.
I actually kinda want to see this just once. I think it would be terrible but I’m not convinced enough to write it off entirely.
Mostly, you want to visually nudge things in one direction of the other until it "looks correct".
Thus you need canvas if you absolutely need to figure out how bad is the bounding box of given font. Because it's the only way to get pixels in js.
It didn't. `justify-content` works with grid too, and will bunch all the grid cells into the center. `justify-items` is if you want the contents of each grid cell to be centered.
Also, `place-content` or `place-items` for grid does both the horizontal & vertical at the same time.
I admit that CSS isn't always obvious how it works, but it seems like the author didn't care to check
This undermines trust in all technical parts of your writing.
Looks like it's not supported in Safari yet.
There's also ascent-override.
The iOS upper right tray stuff looks right how it is, I don't think they were trying to center them vertically with each other. It's treated more like a line of text, with some parts of the icons (outer border of the battery, rounded corners of the LTE bars) dropping below baseline like descenders.
And the Business login screen pushes the centering around because it assigns different visual weight to the UI element versus its label. When the label is on the left (text fields) the centerline shifts right, and when the label is on the right (checkbox) the centerline shifts left. The elements that stand alone (building circle, Business text, Sign In button, Need help signing in text) all keep a consistent line. If you ignore that visual weight and just center them, you probably end up with it looking wrong like a triangle with its bounding box centered in a circle does.
The QuickTime button is just bad though.
For example, the following characters: "jh中"
Depend on the use case, you may want the "中" to align with "j" (for a tight layout like terminal) or "h" (normal articles). But there is never a way to specify it. You just pray that it is correct or your text gets clip out in tight layouts.
Nearly every one of those threads has at least one comment that reads like, “Well I’m a senior web developer and if you don’t like CSS it’s probably because you’re a fucking idiot!” Some will go so far as to say if you don’t like CSS and you’re a man, it’s probably because you’re a misogynist: https://youtu.be/dxY5CdZNzsk?si=BiVr0uPXKIq-T4dJ (Seriously, watch the video, it’s outrageous.)
Meanwhile, more than one web developer has communicated to me in private that they hate CSS and barely understand it after years of using it professionally to make money.
They barely even understand it?? I think the biggest problem with CSS is the same problem plaguing C++ and other older languages. Cruft. If there was proper versioning and pieces of the language were deprecated in favor of modern techniques, it would remove a lot of ambiguity. Heck, if there was a built-in linter that warned you about common errors that would be a massive upgrade!
The only bad part about CSS is that there’s a dozen ways to do everything.
With that said, any developer telling you they hate it probably hasn’t worked with the “state of the art” in other UI development. Go work with WPF, UWP, QT, ImGui, JavaFX, Swing, or any of the dozens of other desktop UI frameworks. Then, try to make a moderately complex style and apply it to several elements. It’s a PITA. I too hated CSS… but then I worked with WPF and JavaFX and lots of those other frameworks: and they gave me a fresh dose of perspective.
I’ll gladly take the ability to do everything a dozen different ways over the inability to do anything that strays from the happy path in the framework I’m using.
I've done web CSS and JavaFX CSS and for app GUI I'd much rather use the latter. For nicely styled documents with good typography on the other hand, web CSS is going to be better.
JavaFX also scores points for having a binary form of CSS that can be loaded and parsed much faster.
CSS as a language is bloody awful of course. The prevalence of dialects that compile down to it is always a giveaway that the language didn't keep pace with people's needs.
And I think vanilla CSS is not that bad. I definitely don’t think it’s bloody awful. Most wrappers around the language added variables and nesting. CSS now supports variables and I think it even supports nesting :)
There’s probably other features that could be good, but for a language that’s just meant to provide style metadata for my UI, CSS works fine.
The problems with CSS are more around the high levels of inconsistency, difficulty making it fast, lack of modularity and the fact that if you make a mistake either nothing happens with no error, or you get visual corruption. It's just an extremely frustrating technology to work with, especially if you only use it occasionally. Although the article talks about font metrics a lot, a big part of why centering things is so hard is thanks to CSS and its legacy which is why it opens with that. Every time I do web design I discover that the current best practice has changed, and there are dozens of new properties with similar names to existing properties which don't seem to work or can only be used in combination with other properties.
Sure, in a normal monitor it is not noticeable but in a good monitor with good blacks and HDR it is super noticeable
Would "the icon is not centered" have sufficed? :)
But I suppose the complaint might be able to be generalized to all items past the start of a main-axis centered flex-box. Doesn’t make the failure more excusable.
Finally you can allow container to grow with the contents.
I was not able to get the nth child variants to work:
The reason is "display: flex" can be a column or row. The "align-items" property describes alignment along the axis, so vertical for column and horizontal for row. The "justify-content" property is the other direction.
```
display: flex;
// The flex axis is the axis where items get added. So horizontal would add things to the right, vertical to the bottom
flex-axis: horizontal;
flex-axis-align: center;
// Normal as used in math to mean perpendicular to the curve
flex-normal-align: center;
```
Or `flex-align: center;` for short.
This would give a decently simpler mental model with only three terms: the flex axis, the flex normal, and the alignment.
And actually it would allow some interesting natural extensions! You could do `flex-axis: path(...)` to specify an arbitrary curve to position your elements on.
Any edge cases I'm missing as to why this wouldn't work?
https://www.w3.org/TR/css-flexbox-1/#box-model
†https://www.youtube.com/watch?v=lKie-vgUGdI
Why not work with the flexibility of the web instead?
https://stackoverflow.com/questions/11419541/how-can-i-get-r...
The problem is that, if it's off by a couple pixels, the front-end engineer may not notice it, and the designer may not even look at it. Or, if they do notice it, they think "do I want to file a bug report right now, or do I want to work on my own ticket right now?" Having worked in both roles, this is my experience anyway.
I agree that there's no consistent way to center things that always works, no matter what, without anybody thinking about it or paying really careful attention. I think we prioritize solutions with those performance characteristics, which is a separate problem of even greater magnitude.
It's absolutely a technological problem because pixel-perfect rendering and alignment is not part of the HTML/CSS specs, when it comes to how fonts get drawn.
The only way to actually get it perfect is to do browser and OS detection and then hand-code a bunch of manual offsets that you keep up to date. And obviously that would be insane.
That's exactly what you do. And that's what I'm saying: the view that the product we're making is not worth doing one-off fixes for, that we need one solution for everything. No other trade has this delusion about everything being a perfect system you can control from a single commanding height (a component library, for example). Even other forms of programming, like game development, don't pretend you can avoid doing one-offs. Just web development, as far as I can tell.
Recently I've learned that even the parts of OpenGL which are fully specified give wrong results on ubiquitous hardware+driver combos at the pixel level. The commonly proposed solution is "instead of using the transforms and blending exposed by OpenGL, do it correctly yourself in a shader." Gosh.
The Apple "Manage" button is the simplest to illustrate. You might think that just having equal vertical space above the M and below the g is the best, but when you read text you're also used to seeing letters stick out of the bottom of the line. So having the g not protrude might look odd.
Or if you have two buttons next to each other, one "Manage" and one "Add" - what should you do? Should you centre Manage, and put the text for both on the same imaginary horizontal line? That will make "Add" look odd when viewed in isolation.
Or should you centre Add? Then Manage will look odd when screenshotted by itself.
Or should you let each have their own vertical centre? Then they will be mismatched.
What to do?
I’d like to use system fonts more often, but apart from the vendor brand fonts like Segoe or San Francisco they are pretty terrible to use all around.
So choosing a custom font and fitting everything around it seems like the solution for now. Apart from that, I’d like to see more support for leading-trim, which will help make things better, at least on the web. https://medium.com/microsoft-design/leading-trim-the-future-...
The long term solution is leading-trim (or whatever it is called now). Pressure your favourite rendering engine to implement it!
https://www.youtube.com/watch?v=K3tZisVDIVk https://practicaltypography.com/ https://beautifulracket.com/appendix/racketcon.html
Ho, and take car of sub pixel when adjusting, they cumulate, and rounding will bite you !
And this works on company level too. The groups that spend a lot of time caring about visuals tend not to give a damm about much else.
Those who just want the thing to work without much regard for the looks of it will tend to use whatever default their UI package comes with, with minimal styling, if at all. It is often not bad in terms of correctness. Defaults may not look great, but they are usually well designed and consistent.
If you have alignment problems, it is often because you tried to do something to the looks, but did it poorly.
Simply, people who care about function wont notice misaligned button. And people who are notice misaligned button usually prioritize visual stuff over everything. That extends to managers and whole companies.
Pretty much no UI package will have everything aligned out of the box, it is not even possible. When you use them out of the box without tweaking, you either get misaligned things.
Maybe, maybe not, maybe it made me not use the app in the first place.
It is one of these little things that make the app look unprofessional. I have been a bit uncomfortable using banking apps with misaligned icons. It the designers can get away with misaligned icons, what can the core developers get away with? If a company is sloppy with their design, maybe they are sloppy with their security too.
People can easily see these visual details, they can't see the back-end but for the lack of information, they will assume it is made with the same care, that is, not much. And maybe they are right.
Some people like esthetics of swiss gardens.
Some people don't mind esthetics of favelas.
You can live e2e in both.
> Are you limited by 1970-s tech e.g. terminal?
This accidentally highlights yet another problem with icon fonts.
Terminal-based browsers with image capabilities, e.g. w3m, can display image-based icons. Fonts on the other hand are (usually) unchangeable on terminal emulators. So if you use icon fonts, it will look like garbage on terminal browsers, but with images there is a chance that it will work.
Sure, who cares, nobody targets w3m in 2024. But the problem can surface for people using modern browsers too, if they explicitly override your font for accessibility reasons. (For example, there exist fonts designed to aid dyslexic readers.)
Then on (relatively) well-behaved sites they will see only a text description; on others they will just see some empty squares.
I care. There's still w3m users out there - and I am one of them.
I don't care if the website looks like shit, but at least keep it usable for us.
Another annoying thing is when they use colors that are a bit different where is should be the same. For things like buttons etc...
https://cssprinciples.com/3/grid/#justify-and-align
"Sure, you could center it on the screen, but what about its position relative to the center of consciousness?"
Because those things can do a whole lot more than just that?
The hardest problem in this article is actually reading it because somebody's cursor is sitting in the way.
Or is this just a bug in FF on this site?!?
It's also why I enjoy being a backend engineer.
Action is truth, appearance is fickle.
~~~~~~~~~~
There are only two hard things in Computer Science: cache invalidation and naming things.
~~~~~~~~~~
Let’s analyse how the joke words.
A quick warning though -
Explaining a joke is like dissecting a frog. You understand it better but the frog dies in the process. - E.B. White
First the Setup —
“There are only two hard things in Computer Science:“
We’ve established there are two things and they are hard, and they belong to computer science. This immediately begins to establish an expectation of technically difficult topics.
“Cache invalidation” is the first example and this is a pair of words that look technical and difficult, even if you don’t know what they are.
This completely reinforces the expectation that the next thing will be even more bewildering.
Punchline:
“And naming things.”
In the third part of the joke - we subvert expectations. “Naming things” is a very down to earth concept, anyone can immediately understand. And anyone can readily appreciate the truthiness — naming things is hard.
This subverted expectation is what makes it a joke.
If the two things were listed in the opposite order, it would still be true and still be insightful - but it wouldn’t be a joke.
The popular addition:
“And off-by-one errors” works even though it is “putting a hat on a hat” because the very first expectation was
“Two things”
… and now we’ve subverted that expectation. And in a paradoxical manner we’ve retained the truthiness present in the first two examples.
So the short answer is - don’t start with the punchline.
Why did `justify-content` became `justify-items`?
I don't agree with the inconsistent naming across the axes, however horizontal/vertical isn't the answer to it.
It pays the bills and is quite fun to do.
Same for Javascript.
Web UIs have made some nice things possible.
The live-streaming pointers is genius too. At first I assumed it was random, then I thought to check in the dev tools for a websocket... I love it!
But even then: just use grid. It works.
I'd much rather use a proper grid layout with subgrids and local/global co-ords same as game dev and in fact I've always wondered if I can just write a web lib that uses webgl to render the page instead. Problem is DOM engines are just too efficient compared to recreating it all myself in js/webgl.
It also helps spotting the bikeshedders.
The visual/optical center is not the geometric center. It is slightly above.
Graphic design basics.
The author mentions the word 'optical' once and 'visual' twice. Never in the above context.
I.e. they never explain this, so we must assume they don't know about it.
And we actually have evidence they don't.
The image below the sentence "Apple can't do it" is an example of visually/optically correctly centered text on the vertical axis. Slightly above geometric and giving the lowercase letters more weight in the decision. Some designers would argue the text should be moved down one pixel in the example at hand but I'd disagree.
The problem here is a different one. The ellipsis (...) is very light, optically, so the horizontal center should account for that and the text moved slightly right.
That is not shown or talked about at all. Go figure ...
Yes, there is a problem, it's the enshittification of design everywhere. Centering not existing is part of it.
As are people like the author who understand the problem but lack knowledge (sea above) to detail a correct solution.
They say "we developers" in one sentence. Graphic design was something you studied at uni when I was young. Just as CS. Maybe I'm just old but you don't know shit about centering stuff in design if you know how to center stuff mathematically.
And yeah, since I'm ranting:
Don't get me started on Material design. Where to start?
Tiny text only buttons that don't even have an outline and whose size depends solely on the length of the text inside. Etc.
Yeah, but in your example 900-700 != -200, and 16-16 != -16
||tonsky.me^$websocket,1p
Incredible, massive, outstand leap from "showing anonymized cursors" to "invading people's privacy"
It feels that way, anyway.
As someone who compulsively scrolls, selects and fidgets while reading, it actually made me quite self conscious to realize that other people would be distracted by my all-over-the-place mouse movements.