Live data from Hacker News

Modern CSS Code Snippets: Stop writing CSS like it's 2015

modern-css.com

301–310 of 318 posts

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#301

Earlier quoted context omitted.

Why can you use CSS conventions in only one project?

He wrote "learn your CSS conventions" which implies that every team and every project will have a different set of conventions. Hidden inside that statement is the fact that he just accepted that Tailwind should be THE CSS convention, something I personally disagree with but to each their own.

No. Tailwind is a way of writing css, not a convention. By “your” convention I’m referring to the problems with the cascade, ie naming classes and so on. I’m not saying tailwind is the only other way. There are many ways to write CSS but doing it with something bespoke for your situation is usually a bad idea.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#302
post #126

Earlier quoted context omitted.

Obfuscate? I can learn tailwind and use it in dozens of projects. I can use tailwind in my project and onboard dozens of developers immediately. I can learn your CSS conventions and use them in exactly one project.

Why can you use CSS conventions in only one project?

You can try to rely on conventions across projects, sure. It doesn’t work well.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#303
post #200
post #43

Earlier quoted context omitted.

The deadest horse in web development is the myth of “separation of concerns”

I don't think "separation of concerns" is entirely dead. Ideally, the CSS is readable and maintainable, and that implies structure. If you have a bunch of (co-)related components, you don't want to find/replace tailwind class names when you need to change the layout. So you separate that part of the layout in classes based on (layout!) functionality. You can see that as "concerns."

Components are the tool you’re looking for. For the rest there’s CSS variables. Soon we may have @mixin.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#304
post #263

Earlier quoted context omitted.

Isn’t that what utility classes are? Shorthand for inline styles? Not saying it’s good/bad, but it feels like that’s the use case

Under that definition any css class is a shorthand for inline styles

There's a big difference between utility classes which are shorthand for inline styles (random example from Tailwind's site where every single class is a one-to-one mapping with a single style override.):

    class="ml-3 hidden rounded-lg bg-gray-100 px-2 py-0.5 text-xs/6 font-semibold whitespace-nowrap text-gray-700 lg:block dark:bg-gray-400/15 dark:text-gray-300"

and semantic names which use the CSS cascade:

    class="main-content subheading"
Calling that a shorthand for inline styles is just being obtuse.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#305
post #4

CSS in 2025: Let's write html inlined styles as if it was 2005 and separation of formatting/representation was never invented. I talk of tailwind, of course.

HTML vs. CSS is a separation of technologies. If HTML was really only about the content and the CSS was only about styling, we wouldn't have to write div soups to style our websites (.container-wrapper .container .container-inner { /* "separation" */ }) and we wouldn't have to adjust our HTML when we change the layout.

We only have to write div soups to style our websites, because people keep misuing a platform for interactive documents for an OS abstraction.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#306
post #275

Earlier quoted context omitted.

As much hate as it gets, this is one thing I like about Angular.

imo Angular would have won had it figured out a stronger path from v1 to v2

From where I am standing it is mostly Angular or Next.js, both have separation of HTML and CSS by default, naturally they cannot block someone to come in and put tailwind on the project.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#307

Earlier quoted context omitted.

CSS Zen Garden is quite the opposite of a good example of your point. Even small changes to the original page layout would completely break most of the provided styles. If I removed the .page-wrapper class it would be also nearly impossible for a different developer to reverse-engineer the issue from the existing Template and CSS files.

Yes, if you remove CSS it does tend to break the CSS.

The point isn't simply "class removal affects cascading", but "anything upstream is capable of placing the original content in an unrecoverable state".

Where "anything" could be your framework, your CMS, you or your coworkers a few years after the original CSS has been written and you can't fully remember what ".format-header__nav-wrapper:not(:last-child) .model-header__nav-wrapper:not(:last-child)" is doing.

And yes, that's a real CSS selector from a refactoring job I'm doing right now.

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#308
post #159
post #81

Earlier quoted context omitted.

Why/how do you grep selectors? Seems overly optimistic to be able to guess the particular rule pattern that is applying a style. Browser tools are much more reliable.

Let's say you're thrown into a website you've never worked on before and asked to fix a styling problem. You can look in the browser tools, but the website will only be running the compiled production version, and if the team knows what they're doing there won't be source maps available. So you've now found selectors in DevTools that you think are causing the problem, and you want to find them in the source code. In…

> if the team knows what they're doing there won't be source maps available

What's so bad about source maps?

Re: Modern CSS Code Snippets: Stop writing CSS like it's 2015

#310
post #237

Earlier quoted context omitted.

"widely available" has a precise meaning that includes Firefox (both desktop and Android). it might be irrelevant for some, but let's not twist industry definitions

Based on marketshare, Firefox can easily be excluded from "widely available"

again, "widely available" should not be intended in the general sense but as a much more precise industry term. "Baseline widely available" is defined[1] as a feature which has been available on all the core browsers (Chrome desktop and Android, Edge, Firefox desktop and Android, Safari on Mac and iOS) for two and a half years

[1]: https://web.dev/baseline

Post reply on HN