Hacker News Reader

Comment by pointlessone | Hacker News Reader

It's because people don't understand cascade we end up with pages that have text in 18 different font sizes. Cascade was a brilliantly simple idea and gave great consistency of design easily. At the time it was great. I believe the only reason most people are mad at CSS is because specificity is hard to grasp and order-dependent resolution and you don't control it when you bundle 500 packages. You get scores of megabytes of CSS that can randomly change order. Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance.

View on HN

And not to forget that this also comes from a discrepancy between the fact a lot of people start with a design and want a CSS that matches that design, when CSS was made more as a theme system where you make a theme and let it handle placement and design. The result is clunky complex CSS to fight the browser into placing things an exact way and giving each element a different look.

In my opinion, this was a failure of communication from the beginning, with a huge divide between "I want my website to look like this because I drew it on paper with my designer friend" and "css is a cool new way of doing decent programmatic ux/ui.

> It's because people don't understand cascade we end up with pages that have text in 18 different font sizes.

Variables and/or utility classes mostly solve this so not sure how it's related.

> Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance.

Similar to inheritance-like features in other languages, I have learned it and find composition is the better default. It's too complex for too little benefit so I avoid it wherever possible.

I find maintainable CSS approaches are all about reducing the blast radius of style inheritance. So people are writing maintainable in sprite of cascading, not because cascading helps.

> specificity is hard to grasp and order-dependent resolution

Specificity is another foot-gun to avoid for me. It's learnable, yet easy to forget later. When you're tempted to rely on specificity there's usually a more readable way to do it that's not going to bite you later.

Do you doubt the developers behind Tailwind library understand specificity and the cascade? They clearly must understand it, use it where it helps, and avoid it where it doesn't.

Cascading does help. When you want to design a document. If you want an application like interface or the same constraints as a magazine page, cascading is the wrong tool for the job. Design tools don’t use it. Layout engines for GUI don’t use it. Flex and Grid is far from the constraints based interface builder in iOS.

> Cascading does help. When you want to design a document. If you want an application like interface or the same constraints as a magazine page, cascading is the wrong tool for the job.

I agree. This sounds like saying cascading helps in simple cases but when it gets more complex it doesn't help.

I don't think anyone really has a big problem writing maintainable CSS for a document. It works fine there. Most CSS methodologies (like BEM) and frameworks (like Bootstrap, Tailwind) are there to help write maintainable CSS code for complex non-document web designs, where a big part of that is taming cascading.

I think a lot of pushback against approaches like Tailwind and JS frameworks are from people that are mostly styling documents. Complex landing pages and UIs are where the real headaches are.

Reply on news.ycombinator.com