..., , and 's talk " that Josh starts off his talk with. We have an image sitting in a container and it turns out that there's this weird gap under the image.
An interesting thing to notice is that the problem persists even if we write it using . So it's fundamentally an HTML/CSS problem.
We can fix it using the first solution that Josh found, in particular, by using line-height: 0 on the section element. And, it's easy to translate that solution to corresponding solutions in elm-css, CSS Modules, CSS-in-JS, and Tailwind.
For e.g. , when you deeply understand the problem, you realize that that's not the best way to fix it. And this led me to a key insight.
Key insight
All these abstractions, elm-css, CSS Modules, CSS-in-JS, Tailwind, etc, that try to abstract away CSS, fail to do so because they DO NOT change the mental model that you have to use to reason about styling problems. They definitely make it convenient to use CSS but when styling problems arise, the person who doesn't deeply understand how CSS works will struggle to find a solution.
Take a step back and think about it. You write in those technologies but you think in CSS. You have to. Those technologies offer no value when it comes to solving fundamental styling problems. How do you even decide when one styling solution is better than another. You have to understand the philosophy of the web, the philosophy of HTML, the philosophy of CSS. It's not all technical. There's a way of doing things and a reason why.
Think about it this way. Suppose a developer joins your team who doesn't understand CSS but is expert at Elm, you know, better than Richard Feldman. You give them an Elm view that's styled using elm-css and has the image in a container problem. Can thinking in types help them find a good solution to the problem? The line-height: 0 solution we wrote in elm-css above passes the type checker. elm-css didn't lead us to a better solution because it's type-safe. No, it's thinking about layout modes that gets to the root of the problem and eventually leads to the better solution. The only way to get there was to think in CSS, not in Elm. It's fundamentally a CSS problem.
As much as we would like to dismiss CSS we still have to learn it. But what about elm-ui?
elm-ui
.
The two major issues I have with elm-ui has to do with rigidity and and as a horrible way to implement a button for the web? Please try to understand what I'm saying. It's not a technological issue, it's a philosophical one. That button is inflexible and inaccessible.
So why do I prefer not to use elm-css et al.?
Simple. They give you more abstraction for very little gain. I took the time to learn CSS a long time ago. I'm no expert but I get by with .
Here's the thing though. I can pick up any of those other technologies in an instant if a project requires it because I know how to think in CSS. Those other technologies just help you write CSS in a different way. Yes, I know the problems they solve are real problems, but, especially in recent years, there are very good alternative pure CSS solutions.
CSS isn't going anywhere. If you plan to be building websites and web applications for a long while then taking the time to deeply understand CSS is a great investment.
Conclusion
elm-css, CSS Modules, CSS-in-JS, Tailwind, etc. are wonderful technologies. Unfortunately, they don't absolve you of the need to learn and deeply understand CSS. If you're already skillful with CSS then by all means go ahead and use those technologies because they can be convenient at times, especially Tailwind, which makes it easy to prototype UIs. But, if you struggle to use CSS and you secretly dislike it, just know that you may be writing your styles colocated with your code and avoiding specificity but CSS will still be on your mind. Except that your mental model of CSS would be so weak that every fundamental styling problem you encounter would just make you hate CSS even more. Don't get trapped in that spiral. Instead, . To learn more about it, please read this announcement.
SOCIAL SHARE CARD GENERATOR