Live data from Hacker News

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

modern-css.com

151–160 of 318 posts

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

#151
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 wouldn't have to adjust our HTML when we change the layout.

You don't have to: https://csszengarden.com/

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

#152

Earlier quoted context omitted.

Tbh there's nothing really wrong with that. You don't need stuff like article or section if you set the right attributes. Often easier to just use divs to get the structure right, and figure out the meaning later.

Well, it does help if you expect sight impaired people with software to find the site useful.

That's why I said setting the right attributes. You can make a fully featured accessible website using only divs.

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

#153
post #13
post #9

Earlier quoted context omitted.

Yeah let's do that. You have everything related to your component on place instead of jumping between files.

Is jumping between files supposed to be difficult or something?

Yes.

The problem is that the styles for something can be defined in multiple places, and that makes it hard. Especially with CSS and (potentially) having specificity issues if things aren't managed well. Having them as a part of the component means that problem goes away.

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

#154
post #43

Earlier quoted context omitted.

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

I was recently doing some very specific web scraping of some very public very static documents. About 25% of them use a soup of divs with hashes for class names. Not a or or in sight. I am fine with the idea of what tailwind does but like at least using semantic tags where appropriate could be a thing.

I'm pretty sure unreadable class names are a byproduct, but perhaps some people may also consider it a feature, of their particular build process.

so they may very well have semantic tags in their development environment. Of course debugging things becomes more difficult for the developer as well unless there is some sort of lookup table to tell them that class .uv.le in the browser maps to .user.name in their codebase, in which case it only becomes marginally slower for some cases.

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

#156

Earlier quoted context omitted.

Exactly this. I wonder if the people downvoted you realize that HN is basically just a big table and a bunch of div, and they use this very site just fine?

As a user, I don't care. As a disabled user with a screen reader, I might care. As a developer tasked with maintaining it after the original dev left, I most certainly would care a great deal.

Besides the points raised here, I think it's worth noting that using stuff like the article tag does not necessarily make things easier to maintain. You do indeed get a lower line count, but you're coupling the structure and meaning. Sometimes that's fine, but a11y can be tricky to get right and it's often easier to push it off until you've got something working first.

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

#157

Earlier quoted context omitted.

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 wouldn't have to adjust our HTML when we change the layout. You don't have to: https://csszengarden.com/

And if you read the CSS there, it's an unmaintainable mess of absolutely positioned elements

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

#158

Earlier quoted context omitted.

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 wouldn't have to adjust our HTML when we change the layout. You don't have to: https://csszengarden.com/

But for that designers should care about the limitations. But they don’t care. Not even about the more basic ones. I’m quite sure many of them don’t even know. Mainly, because their customers are not the one who code.

I got many designs for websites where customers told me that they want a pixel perfect version. The funniest one was when my boss who supposed to be a “senior” web developer told me this. Of course, there is no such thing on the web or really anywhere. Actually, I’ve never seen a design plan in which wildly different aspect ratios and sizes were really considered.

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

#159
post #81

Earlier quoted context omitted.

I like 2-4 but I despise nested selectors. They make selectors ungreppable.

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 the case of many projects, that means searching through hundreds of small CSS files.

That's why you grep selectors, and where the pain comes. You have to start with the most specific rules that you found in DevTools, then start deleting parts from them until you find a non-nested rule that's in the source, yet still specific enough that you haven't got hundreds of matches to go through.

It would be great if something like ast-grep could take a CSS rule copied from DevTools and search for nested CSS that would compile to match it.

Post reply on HN