These are good concrete concepts to use as a foundation.
I would add a general principle that I think is really important: let the layout engine do as much work for you as possible. Which is to say, tell it as little as possible.
If you want that <div> to be narrower, you probably don't want to set it to a narrower `width`, you want to step back and understand where its current width is coming from, and determine how that flow can be shifted upstream to achieve the desired result. CSS is a language of constraints; use them to guide the layout like water, instead of hammering it into place like wooden planks.
When you do the latter, that's how you end up in a quagmire of competing constraints where the sum behavior is impossible to predict, and changing that behavior is infuriating (and often involves `important!`s). That's the kind of situation most people are talking about when they say they hate CSS. For some, it's all they've ever known.
A div? Narrower? Why? Oh because the text is cut off and scrolls sideways instead of running down the page, even though you can't see a horizontal scrollbar?
Ah, well _that_ width is dictated by some image code at the bottom of the page text. The image was cropped incorrectly because the designer was on vacation and they had to use some random online crop tool during our cloud software outage. We fixed it with some additional markup and inline CSS, but the inline CSS was stripped during an upgrade to the latest inline HTML editor we use here.
Anyway, the graphic was supposed to be a flourished section break that was center-aligned, and instead it is now a white bar that is currently even longer than the anchor text that is also overlapping the background imagery.
If you remove the graphic, be careful because it reveals this...other problem, also with the CSS.
You know you can scroll to the left and right really easily if you hold down shift?
I'll link (plug) an article I wrote where I look at a case study that's similar to what you describe and use it to talk about my broader philosophy: https://css-tricks.com/css-is-awesome/
I wrote this a good few years ago and the writing style isn't great looking back, but I stand by the ideas :)
> You know you can scroll to the left and right really easily if you hold down shift?
You can scroll left and right easily, not everyone can. Avoiding the need to scroll in two directions makes content more usable to everyone but there's also a WCAG criterion about it.
All the problems he listed are very real, and its important that a technology fit in our actual working model, not just some theoretical model.
Take his example of the images being off thus screwing up your widths because you chose to inherent the image width as a constraint. Now imagine a very realistic scenario where you are reusing that style across multiple pages, and each page has a different image. Now you need to confirm this works for all existing and future possible images, good luck with that.
Point being, isolating element styles from each other where possible is a big win for maintainability and reliability.
The problems may be real, but blaming CSS for them is both unfair and unconstructive.
You want CSS to solve this problem that other tools and workflows introduce? `article .content img { width: auto;
display: block; max-width: 100%; }`. This is not the solution, but one of many possible.
> ... step back and understand where its current width is coming from, and determine how that flow can be shifted upstream to achieve the desired result.
Step back here is seeing that large images in certain containers push the container out and that you want to avoid this.
If you want CSS to avoid the problems you list, in the first place: that is just unconstructive: The tooling, holiday schedule, poor migrations, and broken upgrades are causing the issues, the constructive solution would be to fix those. And if you cannot, to look at how CSS can help you with them.
> Now you need to confirm this works for all existing and future possible images, good luck with that.
This is not hard at all. It is what both the C in CSS and classes and inheritance solve for you. `img.leader` vs `img.aside` vs `article p.teaser img` vs `article img` etceteras.
Expecting CSS to solve people on holiday is not the point, but expecting a technology to protect me from the much more general problem of other developers and content generators making mistakes is something I think you can blame on CSS.
Going back to brundolf's point, he's arguing that you should try and take advantage of relative constraints as much as possible as CSS lets you do that. I'm arguing the opposite, and so are you in your last line, that the solution is to hardcode those images and decouple the two components.
You can say don't blame CSS as it gives you a multitude of options for how to deal with the situation, but the counterargument is that good tools lead you to a "pit of success" where the correct way is obvious, and CSS is more like a "tiny little bridge out of Moria of success" where you're just asking to fall to your doom.
CSS is designed for professionals is the biggest ret-con I've ever heard. How much effort have developers spent adding basic functionality like scoping, modularity, and variables, features that are table stakes for any "professional" system? CSS was very much designed for amatures at the expense of professionals.
Second, to call CSS simple is insane. How many ways are there to create a positioning root? How many ways to create a stacking context. How many different things can using '%' as a unit mean in different context? CSS is incredibly complex. CSS tries to shove these important concepts implicitly away from the developers notice, only to ultimately make life worse for both amatures and pros.
That being said it's very annoying to read anything that needs to be scrolled sideways. So if I come across it I zoom out and if it's too small to read then I navigate away from the site.
> You know you can scroll to the left and right really easily if you hold down shift?
On macOS, but not by default on Windows. On the other hand, Chrome has adopted this as default behaviour even on Windows, so I guess Edge has got it now too.
> you want to step back and understand where its current width is coming from
This touches on my key insight with CSS (and programming in general), in that if you have a problem with your page layout, that probably probably exists in the code you’re already written, so adding more code on top will only make things more difficult.
Step back, understand exactly why the layout is acting why it is, and address that problem rather than just monkey patching a hack on top.
The problem there is that you're now refactoring a bunch of code that is working on the other 99% of your pages. This model is great, but in CSS when doing this in order to fix your current problem, you are almost guarenteed to break other layouts elsewhere, and very very few people are using automated view testing to see if layouts break.
I think this is the core reason why functional CSS is growing, because by separating out your layouts from each other, one can actually approach CSS refactoring this way without worrying about breaking other pages.
That's good advice. It's also a kind of zen-like approach (forgive me if I am not referring to it by the book). In the past I used to fight CSS by setting all kinds of attributes until it looked half-decent. Now I feel much better by cutting back and lettings the layout engine do its work as you said. Turns out to work better on mobile, too. (Ok let's forget about the dirty media query hacks to shift the last pixels. Move them to a dirty.css and enjoy your other clean stylesheets).
I really like the ITCSS approach - you define your rules the way you’d create a sculpture out of granite. Start by taking a granite block out of the quarry / define the most common rules with widest coverage, then gradually carve the largest details / more specialized rules and then focus on the details.
This way you work with the cascade, as CSS was designed.
Defining sensible defaults and then having a few utility classes for layout helps with this. You could follow it BEM for the rest.
This structure results in minimal CSS that doesn’t fight itself.
The reason lots of developers hate CSS is not because they ended up in a "quagmire of constraints", but in a quagmire of previous developer's constraint...
I've known those things listed for 15 years now, and they did not help with the wack-a-mole problem. Especially not when working with multiple people.
The only thing I've found to actually work is to keep things as simple as possible when it comes to your actual stylesheet. Any kind of complexity including some core CSS properties (e.g. the C for cascading) I avoid. My second box .foo is only slightly different so I will adapt it based on its parent .bar leads to misery. Eventually you will need .baz .bar .foo. Or .bar .foo:not(.shoot-me) and all of that will be burried in 100+K of code done by people that left the project 2 years ago. Hence wack-a-mole. So I try to do myself a favor and just avoid any kind of CSS logic. The complexity will be moved to the template, so not really gone, but at least you can make a change and not worry about something else breaking. And at the very least, if it gets complicated, you can write a test to check if your html code contains proper classes.
I've also found atomic css, such as Tailwind, largely eliminates this problem. Yeah, a controversial opinion, but regardless of how you feel about utility classes, they do avoid this problem.
I used to be a bit of a CSS purist and I thought things like tailwind created a mess where some thoughtful and strategic thinking could prevent it. In reality, preventing the mess costs a lot of time and energy. I'd rather have ugly markup and get things done than have nice CSS. Our users don't give a single shit how nice our CSS is.
I'm on a team of 4 competent people who touch front end code, and despite our experience with it CSS is more of a recurring pain than anything else. We plan to make a slow migration to tailwind, essentially building new things with it and keeping our bespoke CSS in maintenance mode until it's replaced or retired. I'm looking forward to our ugly markup.
I felt similarly before Tailwind. I now put it pretty close to TypeScript on things I don't want to work without.
I think Adam's quote on the front page of tailwindcss.com is spot on "...but the truth is you’re never going to believe me until you actually try it. If you can suppress the urge to retch long enough to give it a chance, I really think you'll wonder how you ever worked with CSS any other way"
I tend to believe that someone who can do magic CSS is about the ability to weave it with Mathematics and patterns. Other than that, the way you use CSS as it evolves become more and more syntactic sugar.
Once you are comfortable with CSS, try to dig a tad deeper into design philosophies and patterns. Work with established designers who understand that spacing is not just margins/padding of a designated number but a rhythm across screens of varying shapes and sizes.
For instance, understand the reasoning why a good designer will tell you that the typographic scale for desktops will be major-third, while for the smaller mobile phones, it will have to be minor-third.
Advance topics to research and have peace with CSS are vertical rhythm for spacings, modular scaling for typography, and the Cicada Principle, etc.
Here is an anecdote to illustrate the above;
There was a "Careers Page" redesign for one of the biggest banks in the world - after about 10+ years of their old one. When I landed in London, they already had a "Senior front-end developer" mid-way into the project. I went as a replacement for one of my team who had a family emergency. I haven't written much code in years.
They had engaged a brilliant designer and had a wall plastered with some of the most beautiful glossy print-outs. Everyone, including the client, loved it. Unfortunately, the struggle was -- the front-end output had irregular margins (pixel mismatch), fix another but breaks the other, etc.
I saw that they had screen rulers that try to match the design with what comes out on the screen.
I requested the designer to spend few hours explaining his reasoning behind the spacing and asked him the rhythms (similar to musical notes) that he has used, the scaling of the font sizes. This was when I realized the designer was brilliant, but the engineers would not understand or appreciate his effort.
I wrote out the Sass functions and mixins and steadily replaced many hacked in numbers and values. Introduced Design Tokens, a simple style guide, etc.
The website is still there and will likely last another 10+ years. I'm also sure many of you might have stumbled on it or have applied to jobs with it. :-)
> the typographic scale for desktops will be major-third, while for the smaller mobile phones, it will have to be minor-third
I tried to google major-third and minor-third with various keywords but couldn't find anything relevant. Could you expand on this and explain what it means?
I did some quick search, and found few ones. You can search for similar ones -- these are beaten topics and have been discussed, blogged, done in length.
- https://utopia.fyi/blog have some good articles, more modern and relevant to the new CSS such as Clamps.
I had fun with Cicada - beautiful background patterns, which you yourself cannot predict. I was looking for my presentation on "Design with Mathematics, and Patterns" (or something in that line) but I think I may have lost it like many other open source files from before Github.
On his personal about page: https://cv.brajeshwar.com/
you can see it was jpmorgon for https://careers.jpmorgan.com/
If you do check that page and some more pages you’ll note there are (on latest iphone) serious design issues.
Ironic that its a career page since they definitely need some work done on that web design.
Usually you can ignore “minor” issues but when its a bank such as jomorgan, a “leading” digital company such as razorfish and such glowing HN comments from the actual people involved you really have to wonder about the state of things.
True, very true. You should have been there with the limitations we had with an arcane CMS they inherited. Every front-end code was not even allowed to interact directly with the back-end. We wrote routines for it to be sucked in, chewed up and spit out. What you see is the final by-product of that gimmickry. I'd still say, really good work by the team with such restraints and limitations -- no real data, all mocks. And yes, I had 45 days to execute and walk out.
I was curious too. Probably https://careers.jpmorgan.com based on his LinkedIn and the fact that he said "Careers Page redesign for one of the biggest banks in the world."
CSS is a lot like the underground infrastructure of NYC. Most of it was happenstance, a lot of it is undocumented or no longer remembered, you ignore the advice of authorities at your own peril, and no matter what you're trying to do it's going to involve a lot of digging.
For me those rules are not the fundamentals. There's more you need to know to actually get CSS to work (and I still usually have to guess and google and try random things to get it to work because my knowledge is lacking)
In particular trying to get content of some flexbox to fill the space provided by the flexbox itself, especially in a single non-scrolling app like page where you're trying to constrain everything to fitting in the window. Like the rule that you have to set min-width to 0 or something to get the desired behavior.
I suppose you could argue that's not fundamental but to me, basic layout that most standard native UI toolkits would provide is an essential feature and yet to achieve it in CSS requires knowing a few obscure tricks
I wish someone would write some other UI language that would translate into CSS so I could write
full window frame
left side
right side
toolbar
content
And it would generate the correct CSS to make it work
To put it another way, imagine you want to repo the Keynote UI or Numbers UI in a webpage. Those are basic app UIs and yet they just slightly less than straight forward in CSS. I'm not saying they are hard, only that most people will have to goole some non-intuitive tricks to get things to work which is a different experience than trying to do them in a native UI kit where it's more likely fairly clear how to achieve it.
It's not quite the same, but CSS grid does make creating those kind of high level layouts much, much easier with `grid-template-areas`:
.header {
grid-area: hd;
}
.footer {
grid-area: ft;
}
.content {
grid-area: main;
}
.sidebar {
grid-area: sd;
}
.wrapper {
display: grid;
grid-template-columns: repeat(9, 1fr);
grid-auto-rows: minmax(100px, auto);
grid-template-areas:
"hd hd hd hd hd hd hd hd hd"
"sd sd sd main main main main main main"
". . . ft ft ft ft ft ft";
}
> Like the rule that you have to set min-width to 0 or something to get the desired behavior
I understand why this is the case (mostly thanks to a patient HN commenter who explained it to me), but holy hell it annoys me how unintuitive it is. You have to set min-width to stop a flex child being too big? Get out of here with that nonsense.
The common wisdom seems to be that 1D layouts should use flex and 2D should use grid, but I don't think I agree with that. These days, I only ever use flex for layouts that should actually be flexible. Even if it's a single dimension, if it's fixed-widths it's straight to grid for me now, and my life is measurably better for it.
I think there is a very easy fix to most HTML/CSS problems when building GUI on the web - use HTML5 canvas.
HTML is not a good match for GUI and CSS is not a good match for...anything.
HTML5 canvas brings you to where Windows/X was 25 years ago so instead of trying to build GUI using TUI, just use the damn GUI already.
Sure, the whole lot of tooling is missing but some copy/paste/fix from either Windows or X should produce better result than S*T ton of HTML/CSS/JS that is currently there attempting (and failing) to emulate Windows/X GUI.
That's not really a fix, though. Flutter is trying to use this approach and if you go to their demo sites you will notice things feeling slightly off: https://gallery.flutter.dev
Some of the notable drawbacks:
- you can no longer select text on the page, anywhere
- right click doesn't work like you'd expect it to, either, since you're looking at a canvas
- currently the download sizes are absurdly large, since you need to pack a large amount of functionality in .js/.wasm (over 10 MB, actually)
- for simpler pages, the performance overhead will be very noticeable, just try zooming in or out in those pages (i got <2 fps while zooming on a decent desktop computer)
- essentially all of the former accessibility benefits of DOM are now gone and screen reader support needs to be developed anew, assuming that they'll even support your canvas based solution
- furthermore, learning about websites by inspecting source to see how they did it is no longer possible; and you can no longer crawl these sites in any sort of an automated manner, which may be a good/bad thing depending on how you look at it
I'd say that most GUIs should be simple enough to work well with DOM, instead of throwing away decades of progress while chasing niche goals. HTML and CSS are great for displaying all sorts of documents and personally i think that the web should not stray too far from that - utilitarian interfaces that are simple and easy to understand, rather than sci-fi ones like portrayed here: https://www.saji8k.com/kit-fui/movie/
Canvas doesn't bring you do Windows/X11, Canvas brings you to a basic VESA driver where you're plotting pixels manually. You think the JS framework churn is bad now when all of those frameworks are just layers over HTML, just imagine the world we're looking at if everybody is writing their own full GUI framework to work with canvas. At least with JS framework hell everything is guarenteed to have the same output format that we can then interact with with our common set of HTML tools, with Canvas all bets are off.
I get where you're coming from, I really do. HTML5 and CSS are just bad tools for doing GUIs. But there is so much infrastructure built up around them that just overrules any advanage we would get hand rolling a GUI directly rendered to canvas.
Is there something better? With Qt Widgets, the poster child for cross-platform GUI toolkits, I also frequently have problems with getting the layout to behave the way I want.
Cross-platform and being a good tool are orthogonal concepts. We use HTML/CSS for GUIs IN SPITE OF their general unsuitableness because the value of easy distribution wins over developer sanity.
> Cross-platform and being a good tool are orthogonal concepts.
I agree, but when I need to develop some software for Windows and Linux, a great toolkit for Android or iOS is of no use to me. Similarly, I won't use a Linux-only or Windows-only toolkit, as awesome as it may be, because I'm not going to build two different GUI layers.
If you don’t use the DOM you need to reimplement your own accessibility tree and bind that into the access APIs. Or choose to be specifically illegal in a bunch of important markets, and potentially illegal in the US.
To me, CSS is probably the most "artistic" kind of work I do, so a good CSS writing session involves being in the right artistic headspace. The work is a lot like shaping clay--a little padding here, some flexbox there. I use classes scoped to components and avoid global styles, lessens the blast radius. I also leverage CSS variables in lieu of SASS and friends to keep things vanilla. Once it's done, like playing with clay, I couldn't really describe the process of getting to the final product, it just materializes over the iterations.
I definitely find `box-sizing: border-box` fits my mental model much better.
I rarely find a need to think about `positioning` though and I think the article doesn't give enough credit for `display: flex` and `display: grid`. I tend to reach for `display: flex` as a default and find it much more intuitive. Whether it's easier for a beginner is a different question though.
I feel ashamed not knowing about this option. content-box has caused me so many troubles over and over again, and I didn't know it had such an easy solution.
I worked some years as a full stack web dev, and css was mostly what blew up my time needed. I recently built a small landing page and now I officially gave up on CSS. I just don't want it to be a part of my professional life anymore. I guess I lack some fundamental design and layout concepts but I don't want to fix this. I might as well run a bakery.
Learning flexbox is when CSS started clicking for me. I may abuse `display: flex` everyone once in a while, but it can truly be used for a lot of ideas.
I often use flexbox for tiny things like vertically aligning a checkbox and a label and I still don't know whether this is the correct "scope". Like, can I have tens or hundreds of flexbox containers on the page? Does flexbox even take significant time to process, compared to some other css constructs?
I once inherited a project where the previous "webbed" had forced a lot of css formatting using "!important". I wanted to pull out my hair because of how unpredictable everything was.
As a frontend engineer who started 15 years ago, learning the box model required a lot of knowledge of the internals of the browser. The times of having to know things like quirks mode, abusing overflow hidden [1], how to break the behavior of float, etc are long gone. This is great both for us having to struggle less, and for the newer generations to be able to tackle harder problems than just layout and build cooler stuff.
The article is well written, good reminder for all of us who works with css.
I still remember learning all of those things years ago. However, because I don't use vanilla css, I mostly always have to re-google them again.
Actually, for the past few years my css in both professional and side projects has always used tailwind in React (except for react native), 95% of the layout are flexboxes and grids.
I think these are most of the guiding principles that I wish I understood a lot sooner than I actually did. I spent a lot of time fumbling around, tweaking CSS back and forth, and not really understanding why things weren't behaving as expected.
> To apply border-box to all elements on the page, make sure you have something like this snippet in your stylesheet (a lot of CSS resets will include this anyway)
I think the answer has to do with calls to action and the assumption users make that the cursor hand is a link to another web page or another part of the site, while not all buttons are hyperlinks. Probably not as much of an argument in these days, though, especially as most sites are single page applications where basically every button does indeed do some sort of reroute, target blank (new tab), or network call at the very least.
Also, to be pedantic, not all buttons are entirely clickable, only small portions of them.
Edit: Interesting that HN doesn't use the cursor hand for reply / updating. ;)
the only thing IE ever got right was treating box-sizing: border-box as the default. I work with CSS all the time and have no idea after all these years why anyone would want to base it on content size if they plan to use any padding at all.
> CSS can be hard to grasp when you're starting out. It can seem like magic wizardry and you can very easily find yourself playing whack-a-mole adjusting one property only to have something else break.
Looking at the site, I'd say that some of the information are well described. Still, a lot of people get confused on the box model might as well on the flex box, grid and manipulating transitions and animations.
Based on the way the article is written, I assume that software engineering was not new to the author when he first started writing CSS. It seems strange to me to write an article like this because it's just an indication that the author chose to dive in without understanding the fundamentals first.
I'm honestly just trying to understand how articles like this get promoted to the front page of Hacker News more and more often. I imagine that writing an article about [insert related field of mathematics] before diving into [insert field of physics] every week would not land me on the front page of Hacker News every week.
> it's just an indication that the author chose to dive in without understanding the fundamentals first
You'd be surprised how many otherwise-competent engineers don't take CSS seriously enough to seek out the fundamentals, and instead spend their days avoiding it as much as possible and cursing it when they can't
I totally avoid CSS at work because it’s just an insane whack-a-mole spaghetti based upon our own SASS framework written by a few designers that had to learn CSS without any mentoring (since they are in their own « design » team), and don’t understand the consequences of what they do.
So yes, I totally spend my days avoiding it. Not because I hate CSS (I love it in some way, and I miss writing elegant stylesheets) but because CSS is a delicate tool that is hard to be maintained by more than a few people.
I'll agree that it's a delicate tool. Similar to Lisp, CSS is very elegant in the right hands but also heavily reliant on the devs sticking to strong conventions and principles. On solo projects, or projects with just a couple of devs, it can be wonderful. But it does tend to have trouble scaling.
Which is why, even though I don't love them, I respect the usefulness of things like CSS Modules that impose more scoping and constraint over CSS codebases. For bigger teams they do tend to be necessary.
There is a stigma amongst "real programmers" against "web developers". So a "real programmer" will never become adept at CSS because it doesn't appeal to their ego
The question then comes, where would one go to learn the fundamentals-and what are they now?
Being someone who was ahead of the game in css 15 years ago, but not having touched it since - where would one go to understand the new fundamentals and options available?
Personally, I think flexbox is the single most versatile and important tool to be familiar with. You can create nearly any layout with it, in such a way that it's very naturally responsive almost by default.
Maybe I am wrong, but I would assume that the most sensible place to start with is the MDN Web Docs[0] in this case instead of looking for blog posts.
Throwing out blanket statements is dangerous for new comers, which seems to be the target audience of this article according to its title. For example, collapsing margin isn't always bad and unpredictable, it just seems that way if you didn't take the time to understand the fundamentals behind and go for "what works".
That's not too different to telling CS students to not worry about learning the memory and time complexities of different algorithms and just use [insert "best" algorithm] because it works most of the time.
I would add a general principle that I think is really important: let the layout engine do as much work for you as possible. Which is to say, tell it as little as possible.
If you want that <div> to be narrower, you probably don't want to set it to a narrower `width`, you want to step back and understand where its current width is coming from, and determine how that flow can be shifted upstream to achieve the desired result. CSS is a language of constraints; use them to guide the layout like water, instead of hammering it into place like wooden planks.
When you do the latter, that's how you end up in a quagmire of competing constraints where the sum behavior is impossible to predict, and changing that behavior is infuriating (and often involves `important!`s). That's the kind of situation most people are talking about when they say they hate CSS. For some, it's all they've ever known.