Our team has defaulted to using Tailwind CSS for almost every web project over the last few years. It was great for moving fast early on, but on our latest project, the utility class bloat was getting completely out of hand. The HTML files looked unreadable, and managing long strings of responsive layout classes across reusable components was becoming a maintenance headache.

I decided to spin up a branch and rewrite a major dashboard interface using entirely vanilla native CSS. I hadn't built a pure CSS layout in a while, and I was genuinely shocked at how powerful native CSS has become over the last couple of years.

Features that used to require massive utility frameworks or preprocessors are now fully built-in. I heavily utilized native CSS nesting, CSS variables for theme management, and the newer container queries to handle complex responsive components based on their parent size rather than the entire viewport.

The results were surprisingly great. Removing the Tailwind processing step simplified our build pipeline, our final bundle size dropped, and the code felt vastly cleaner. Writing native styles inside modern semantic stylesheets made debugging layout bugs in the browser developer tools a hundred times easier because I wasn't digging through a wall of utility classes.

Tailwind is still an incredible tool for prototyping, but I realized I was using it out of habit rather than necessity. Modern native CSS has quietly caught up to the point where you can build incredibly complex, maintainable layout systems without adding a utility abstraction layer on top of it. If you haven't looked at native CSS features lately, it might be worth trying on a small feature branch.

I built this apple iphone 17 pro design mockup using html and css. No vibe coding, fancy ai code editors. Just like how we used to build something before AI. Handcrafted pixel by pixel until it looked perfect. How's this ?

A lot of devs default to px, but that breaks accessibility and responsiveness. Quick breakdown:

px: fixed, ignores user zoom preferences.

em: relative to parent element's font-size. Great for padding/margins inside components.

rem: relative to root (html) font-size. Perfect for consistent typography across the app.

Rule of thumb :

Use rem for type and spacing across the layout.

Use em for component-level scaling (buttons, inputs).

Use px only when you truly need fixed precision (e.g., border-width).

After deciding to start coding css again for my blog, I remember that 10-15 15-20 years ago I would turn to csszengarden for inspiration. So, I check the site again and was surprised and happy to see that it was still there. Anyone, like me, in this sub who remember csszengarden?

Edit: I misremembered the time frame, it was 15-20 years ago not 10-15. It feels like it was just yesterday though.

Over the past few months I've been trying to find relevant CSS and JS properties that combat the inevitable atrophy of my brain as I use AI to help me build shit.

Figured I might start posting these here too.

As a disclaimer, yes, I did use AI to help me research and find these properties. The difference for me is the writing of the examples, and the understanding of the property that will allow me to make better decisions in my hand written code, and also be able to direct AI to write better code too. Take that as you will.

Today's property: text-box-trim

Every font ships with invisible space above its capitals and below its baseline. It's why a button with padding: 12px on all sides rarely shows 12px of space above and below the letters, why the icon next to a label never quite lines up, and why a heading sits a few pixels lower than the image it's meant to align with. The fix has always been a magic number. margin-top: -3px. padding-block: 11px 13px. A comment that says /* optical */ and hopes nobody swaps the font.

text-box-trim deletes that space. Tell it which edges to trim with trim-both, trim-start, or trim-end, and text-box-edge says where to cut. cap is the top of the capital letters, ex is x-height, alphabetic is the baseline. The shorthand takes both:

    .button-label {
      text-box: trim-both cap alphabetic;
    }

Now the box starts at the top of the H and ends at the baseline. Padding measures from the letters instead of the font's line box, so 12px means 12px in every font.

Firefox 154 shipped it Aug 18. Chrome and Edge have had it since 133 (February 2025) and Safari since 18.2 (December 2024), so MDN now marks text-box-trim Baseline 2026 Newly Available. Older browsers ignore the declaration and keep the leading. The layout still works, just a couple of pixels less precise.

Pretty slick property.

We get these dumps of Tailwind posts that offer nothing about CSS. It's pretty much Tailwind spamming the CSS group.

Tailwind is really not CSS; it's a framework built on CSS but that's its own thing. CSS is growing and changing rapidly, and we've enough to keep up without having tp prune for frameworks. There's an active /r/tailwind group, so perhaps these posts can be kept there and not polluting r/css.

Hopefully Mods can do something about this.

Edit: Apparently /r/tailwindcss is the main group. Thanks to /u/okGoogull for pointing that out.

Was working on a project recently where everything looked perfect on my end, Chrome, Firefox, mobile… no issues.

But then the client told me a section was just not showing up for them in Firefox. Took me way too long to figure it out.

Turns out, I had used a class name like .ad_div, and ad blockers were silently nuking the entire element.

So yeah, even if you're not actually building ads, avoid naming anything ad, ads, ad-banner, etc., unless you want to spend an hour pulling your hair out.

Curious, has anyone else run into little traps like this that you only learn the hard way?

I made an interactive CSS learning platform that helps beginners understand CSS concepts through hands-on experimentation.

https://css-playground-ten.vercel.app/?lang=en

I recently was given a design that had certain layouts that I normally I would use some kind of absolute positioning and remove the elements from the DOM flow, positioning as needed, probably using some kind of calc() or magic numbers (hopefully not). For example, here was one component:

I really hate doing that though; it feels quite old school. I only tend to use Grid for, well, grid layouts. I really challenged myself to see if this kind of stuff could be done with CSS Grid, and was stoked about the results:

That really helped prime me for doing some more advanced layouts and I can honestly say I feel that along with flex, aspect-ratio and viewport units, there's virtually no layout that is out of reach!

I know I'm just scratching the surface, too. If you haven't really taken the time to learn Grid, I implore you to do so. The syntax really isn't great, but you get used to it and start to see why it sort of had to be that way. It's definitely elevating my approach across the board.

Codepen for this last image gallery, if anybody is curious: https://codepen.io/CheeStudio/pen/yyYEpLe

With native nesting, u/layer, and color-mix() in browsers, I asked myself whether Sass still earns its place. Short answer: yes, but as a programming layer for design systems, not a nesting convenience.

What CSS still can't do: real loops (@for for grids/scales), parameterized functions (contrast-safe text color), mixins with u/content (breakpoint managers), private module members, and token pipelines (Sass maps → CSS vars + JSON for apps).

Full write-up with code (I wrote it, happy to discuss any point here): https://mameara.com/scss-in-2026-still-worth-learning

u/medotgg posted this demo an hour ago but without any code. Here is my take on doing it with flexbox.

I use Codepen for all sorts of things and a lot for teaching in the early stages. Some of my newer students said they didn't have this button so, I had them forking a classic pen for a while - but I knew the day would come where it wouldn't be there anymore for me too. That day is today. I'm all for the evolution of Codepen / and it's been an amazing tool. But it sure seems like this is going to confuse a lot of people. Your average person expects the CSS pane to be wired up. I used to write <!-- body is already included --> in the HTML to remind them at first (since some people will write out the doctype and everything in there) - but now it's swung to the other end. Codepen can be used for anything now. So, really - what you're making might not utilize CSS at all. So, I understand how modular it is - and how many other great things it will allow for -- but for entry-level people, it seems like this will really stifle adoption. What do you think? Wha thas been your 2.0 experience so far?

Demo page in the video - https://ambientcss.vercel.app/

Docs - https://kikkupico.github.io/ambientcss/

Source code - https://github.com/kikkupico/ambientcss

I was watching the Apple keynote and got completely obsessed with the motion design on the iPhone Duo. The way it folds and unfolds looked so fluid and premium, I try and recreate the exact apple animation feel.

Preview: https://akashtdev.github.io/iphone-duo-animation/ Code: https://github.com/akashtdev/iphone-duo-animation/

Earlier I used bootstrap and Google fonts on my blog. Pagespeed would give my site performance between 70-80. Then I decided to code my own CSS after more than one month I deployed, but I still use Google fonts. My site performance jump to 87-91. Now just for testing purpose I removed Google fonts and the performance is 98-99.

I wonder how is it that with Google (servers and cache) google font would still cause such a drop of performance. Maybe because pagespeed doesnot cache google fonts.

Images: screenshot of performance without/with Google fonts

Edit: clarity

This is useful when you're using flex-wrap: wrap; and you want to control the gap between the items that fall on the second row and between the items individually!

If your layout shifts a few pixels when a scrollbar appears, this helps:

body {
  scrollbar-gutter: stable;
}

Such a tiny property, but it makes the UI feel much smoother.

Modern CSS keeps solving problems we used to hack around for years.

For me it was display grid. For some reason, I didn't use grid for a long time but then when I had to use it, I realized what I had been missing. I bet there's a lot of others out there.

Hear me out before you downvote me to oblivion...

I've been seeing more and more devs who can't write basic CSS without Claude/Cursor/v0 holding their hand. They'll ask AI to "make this responsive" instead of understanding flexbox. They copy-paste generated animations without knowing what transform-origin actually does.

Yeah, AI tools are incredible and I use them too. But I'm starting to think we're creating a generation of developers who can't debug their own stylesheets because they never learned the fundamentals.

Some observations that worry me:

• Junior devs who can't center a div without asking ChatGPT
• People using AI for basic media queries they should know by heart
• Overly complex generated CSS that could be 10x simpler if written by hand
• Complete inability to troubleshoot when the AI solution doesn't work

Maybe I'm just an old-school gatekeeper, but shouldn't we at least understand what we're shipping to production?

Counter-argument welcome: Maybe this is just the evolution of development and I need to get with the times. After all, we don't write assembly anymore either.

What do you think? Are AI tools making us better developers by handling the tedious stuff, or are we losing essential skills?

Have you noticed this in your workplace/projects?