CSS is hard no matter how good you are at it (opens in new tab)

I want to thank both you and the original article author for bringing this issue up, because until this article and this comment I never really understood the use of the vertical-align CSS property. This is the perfect example to illustrate the actual use of this property. Playing around with the author's codepen and seeing how it changed when I added the vertical-align CSS property really unlocked something for me.

> The flexbox container inside pill2 "hides" the inner text, so pill2 is treated as having no text at all (for layout purposes). This is treated the same as a font having zero height. So the browser aligns a 16px font (or whatever) with a 0px font, and it comes out misaligned.

That’s actually not what happened.

Images have their baseline at the bottom edge, so Pill 1 is simply aligning its text to the bottom of the <img> element which is the first item in Pill 2.

You can confirm this behavior by enlarging the image, you can see Pill 1 shifting vertically to align the text baseline to the new bottom edge of the image.

You can also swap the order of the <img> and <span>Pill 2</span> so that the text goes first. You will see that they will now align despite the fact that the inner text is supposed to be “hidden”.

An easy way to solve this is to give .wrapper a hidden pseudo element with a bit of text so it becomes the first item to be used for alignment.

.wrapper:before { content:"a"; width:0; visibility:hidden; }

You can also just set the image as background to avoid the <img> element altogether.

`vertical-align: middle` would also likely give them better preferred alignment the first time a "pill" thinks it needs a second line of text and sometimes when too many pills exist for available width and the container starts to spill to another row.

I understand why `vertical-align: baseline` is the default, but it seems like such a bad default for all the ways designers like to (over) use Flexbox. (Especially because designers really love the baseline alignment at first but often can't seem to think two and four dimensionally enough when designs meet real world constraints and user data and need to expand/contract/shift to available space.)

That's a much better solution than altering the content.

This is correct. See here for some more examples:

- https://codepen.io/romellem/pen/rNZbPZQ

TL;DR: whenever you are using `display: inline-block`, be aware of `vertical-aign` issues that may crop up.

You are absolutely right here. This problem arose because the surrounding code was much older. I would have liked to reformat it, but that would have been a huge lift compared to what I was trying to achieve.

"Modern CSS" defined as ... what, precisely?

Keyword searches seem to pull up an unstructured soup of random essays and 'tips-n-tricks' type articles.

Sass helps with reusable code. Bootstrap and standards also help a bit. Bulma, PureCSS, Tailwind (Pro), Concise. These provide a good starting point.

My issue is, ever since 1997, the spec hasn’t really lent itself to composability. Just a list of definitions. Maybe some shareable effects but not idempotent in and of themselves. From tables, to floating divs, to grid 960, to flexbox. We keep inventing new ways of dealing with the shortcomings of the standard.

Inheritance and composition should be paramount. Sass and Less help but still fall short of the ideal state.

When I encounter a “this isn’t lining up” problem. I think about the composition first before I think about styling. Should I put it in a div and give that the right properties that I can then shim a span in there with the rest of the required style? Or do I need a new style definition to achieve the look. I try to avoid creating new styles if I can.

There is no one silver bullet to clean up CSS. I think much of the problem is that many developers think of clean CSS as an afterthought. The same level of care and organization should be applied to CSS as you would apply to the rest of your code.

I have found that there are many tools out there:

- Design systems - Web components - Frameworks - Naming conventions - Higher level transpiled languages

Tools are meant to be used together, not in isolation. Any sufficiently complex app or page can benefit from mixing and matching these tools. At Aha! we have a design system, we use the BEM naming convention, we leverage web components, utility classes, and LESS.

With so many tools you can definitely get yourself into a mess unless you apply each one appropriately. That is where experience, discipline, and good old fashioned code reviews will help prevent a CSS nightmare file.

It depends on what you're building. For a simple website that only uses a few tags, a single file should be enough, but that's no challenge.

I think the problem starts with the phrase "a css file". If you're building something complex, you gotta bite the bullet and split things up.

If you're building apps, one way is doing self-contained components, which share absolutely nothing between them. You can have a "base CSS" for the page that is very small, just a few lines (plus maybe a reset), but the rest of the style should be "owned" by components and scoped to them using whatever methodology you choose.

Another possibility is going the completely opposite direction and having only helper classes (like Tailwind) that know absolutely nothing about the elements they're styling.

I don't believe in a middle ground. A lot of messes start by having a single CSS block that is responsible for styling 20 different parts of the screen with a very complex CSS selector targeting multiple components. This is like a COMEFROM in INTERCAL. I don't think you can't have your cake and eat it, except in toy projects. If you want to have a single-source-of-truth for colors, you gotta use variables (SASS, native CSS variables, etc), or a helper class.

Working with frameworks also requires care when you want to slightly change the default appearance, and a lot of people abuse !important for this. You don't have to do it.

To avoid !important when you want to "extend" some third-party CSS, use specificity rather than !important. Have a root class, for example .my-app-with-custom-style (it can be applied to the body tag or some other root element), and then extend each block of the framework using the root class + the same selector. For example, if your framework is .b-button.main-btn and you want to extend it, extend it with .my-app-with-custom-style .b-button.main-btn. This way specificity wins and you don't need !important.

Tailwind * tries * to resolve this, but is probably just a different bird's nest.

Are you building sites or apps? I got to the point a long time ago where I just didn't care to cover every single design need and just made my own mini-framework.

Ask ChatGPT to do it for you. It does surprisingly well.

Flexbox is way better than what there was before, I'll grant that. Grid too.

Ouch. I just realised I am old.

What do you mean by "get to grid"? Have people come back around to the idea that tables weren't so bad?

I enjoyed web development quite a lot in the '90s, but after CSS came along it was an endless source of frustration, and I gave up on it all.

What language/tech should CSS have looked to?

I never enjoyed making graphs with most APIs whether it was products like Matlab and IDL or xvgr, not to mention pyplot, highcharts, etc.

I was initially apprehensive about making plots with D3.js but once I got over the hump it was such a breath of fresh air. Instead of the usual second guessing, head scratching and "you can't get here from there" it was just... easy! Want bar charts by date where the weekends are a different color... easy!

I'd also point out the endless complaining people have about things like puppet, terraform, kube files and such. I always found that building out cloud infrastructure with Java or Python programs that use the AWS/Azure API and write bash scripts that boot up on the machines or Python programs was... Easy! Often I'd have complicated systems up-and-running and checked into git while people were still fighting with leaking abstractions with various value-subtracting tools that never absolve you from knowing bash.

I agree. The problem that people are having is that CSS has completely changed within the past 5 years, especially positioning, as all of the modules have been implemented. Things that once involved elaborate and fragile rituals to perform are now trivial to write. If you knew CSS 10 years ago and never went back to survey it since, you don't really know CSS now.

I finally stopped claiming I knew CSS until I took a few months to work through a top to bottom overview. None of the skills I had 10 years ago apply to modern CSS; I had to give up every habit. This is a good time to do a review, because CSS development seems to have slowed down considerably, and browsers are all pretty good.

However, CSS has become very big, and web development teams should really start respecting it as a specialty in itself, and making sure they have at least one person who knows it all. Even if they use tailwind.

I agree, but I'd even say that becoming pro at CSS is orders of magnitude easier than becoming pro at your average programming language. I think engineers just tend to not take the task seriously, and don't apply themselves enough.

You just need to actually understand the box object model and a handful of common gotchas.

!important is like global variables

Sure they have their place, but goddamnit do some people abuse them and make huge messes with them :(

Better off repeating classnames (.foo.foo { color: pink; }) than using !important.

Not a fan of tailwind but grid by default is indeed a good basis for a design system and solves this easily.

Not sure why you are getting downvote. I absolutely agree - avoid the C in CSS and your life will be much better.

The problem this article is pointing out is that you could have that database and still struggle.

It is easy to make a database of effects that work in isolation, for that matter GPT-4 will do a great job writing CSS to make isolated visual effects.

It’s when you need to put those visual effects to work inside of a real application or web site that you find it doesn’t work or rather almost works because of very fine details in how HTML and CSS work. Often you find you can move something forcibly a few pixels this way or that way but what works for the personal web site will be a nightmare for a complicated application that has multiple parts that multiple people are working on because you’ll need more hacks to deal with the consequences of those hacks.

It is real, global, and comprehensive understanding we need, not just another cheat sheet.

`position: relative`, `overflow: hidden`, `height: 100%`, `line-height: 1` and `margin: 0` solve a surprising percentage of CSS issues in my experience.

!important generally.

I have a hard time differentiating when I should use grid and when I should use flex-box. In this case, setting up a grid seems like overkill.

Seems more like a browser default issue than a tool choice issue.