My First CSS

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.

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 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. :-)

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.

https://makandracards.com/makandra/66994-css-flex-and-min-wi...

That's not the only gotcha

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.

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.

> box-sizing: border-box

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.

This is a great list! For someone starting out with modern CSS I’d add: a working knowledge of Flexbox, and media queries to enable responsive design.

> A key way I think about building visual UI components is that basically everything can be broken down into a bunch of rectangles on a page.

I created this tiny script[1] in order to be able to view all the rectangles that makes a website, a little while ago. Here's a demo[2].

[1]: https://gist.github.com/corentinbettiol/85a8938175f89a15ac35...

[2]: https://up.l3m.in/file/1597168094-tilt.webm

>CSS can be hard to grasp when you're starting out

The browser differences especially for the box model were the bigger problem.

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.

This makes me very happy.

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.

[1]: https://css-tricks.com/clearfix-a-lesson-in-web-development-...

Front Ender sounds like a Minecraft boss

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)

They will? I didn't realize that.

Why don't <button>'s default to: "cursor: pointer;"?

> Everything is a rectangle.

I remember a time when everything was a table.

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.

Only if you learned from the wrong source.

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.

Edit: "basic field" -> "related field".