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
(It is a good article!)
reply