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.

It's 2026, are you still using vanilla CSS for your latest project?

sibling-index() and sibling-count() went widely available last week when Firefox shipped support — which means Chrome, Safari, and Firefox all agree on them now.
I spent some time seeing what that unlocks for UI patterns that used to need JavaScript

Full writeup with live, editable demos
https://willunmount.sabarni.in/blog/css-sibling-index-sibling-count

edit: note this works only on chrome. as HollandJim pointed out these features are only available in firefox, safari developer preview.

Or, alternative title: how I accidentally invented progress() but still shipped it anyway...

Dragging the sidebar. The window never moves, so every media query on the page is reading a number that did not change. Here is how that works, starting from the beginning.

How we do it today

We want a heading to be 24px on a phone and 40px on a desktop, so we write steps:

h1 { font-size: 24px; }
@media (min-width: 768px)  { h1 { font-size: 30px; } }
@media (min-width: 1200px) { h1 { font-size: 40px; } }

At 767px it is 24, at 768px it jumps to 30, and for every other property that should follow the screen we write the same set again.

Fluid

The known fix is one line that draws a straight line between the two ends:

h1 { font-size: clamp(1.5rem, 1.167rem + 1.667vw, 2.5rem); }

24px at 320, 40px at 1280, pinned at both ends. The two magic numbers are an intercept and a slope, worked out by a Sass function or a calculator. Utopia and most modern frameworks use it for their spacing and type tokens.

Where it stops

It only works for lengths. vw is a length, and degrees plus a length does not type-check, so rotate, transition-duration, font-weight, opacity, scale are all out. The browser drops the whole declaration. For those, we go back to steps or pick one value and live with it: the drawer that opens in 0.3s on a phone and on a desktop while travelling three times the distance.

The trick

Swap the order of operations. Divide two lengths first, which gives a plain number from 0 to 1, then multiply in whatever unit you want:

:root { --t: clamp(0, tan(atan2(100vw - 320px, 960px)), 1); }

font-size:           calc(24px + 16px * var(--t));
rotate:              calc(-7deg + 14deg * var(--t));
transition-duration: calc(0.14s + 0.96s * var(--t));
font-weight:         calc(400 + 220 * var(--t));

--t is 0 at 320px, 1 at 1280px, a fraction in between. Write it once, use it everywhere, no breakpoints, no keyframes, no JS. A bare / between two lengths is Chrome 140 and Safari 26 only, so the division is spelled tan(atan2(a, b)), the trick from Jane Ori, which has worked everywhere since early 2023. And it runs downhill too, which clamp(26rem, ..., 2rem) cannot, because min greater than max returns min forever.

The better trick

Change 100vw to 100cqi and --t measures the nearest container-type: inline-size ancestor:

.sidebar { container-type: inline-size; --t: clamp(0, tan(atan2(100cqi - 128px, 288px)), 1); }

Now a component follows the width of whatever it sits in. Same markup in a 240px column and a 520px column on one screen comes out different on its own, with no -small / -large variants. That is the GIF at the top.

The part where I found out

After building this I found out CSS already ships it: progress(100cqi, 320px, 1280px) does exactly that division. Chrome 138, Safari 26, and Firefox 155 as of September 1st. I had reinvented it from scratch, with a Sass wrapper.

Shipped it anyway as cq-lerp (npm i cq-lerp, npm), because the tan(atan2()) fallback works back to early 2023 and a 'supports' block upgrades to progress() where it exists:

--cq-t: clamp(0, tan(atan2(100cqi - 320px, 960px)), 1);

@supports (opacity: progress(1px, 0px, 2px)) {
  --cq-t: progress(100cqi, 320px, 1280px);
}

The Sass side is one function for every property and every unit. Min, max, done:

.card { @include cq-track(); }

.card .badge {
  rotate:              fluid-on(-7deg, 7deg);
  transition-duration: fluid-on(0.06s, 1.4s);
  border-radius:       fluid-on(6%, 50%);
  font-weight:         fluid-on(200, 900, var(--cq-t), "");
}

Every effect above is one fluid-on line. There is a plain CSS build too if you do not use Sass.

Demo, resizable, no JS: https://subamanis.github.io/cq-lerp/ Source: https://github.com/subamanis/cq-lerp

i really cant understand the difference between them i watched multiple and asked llms and still cant wrap my head around it

Built a Chrome extension that shows computed styles (color, font, spacing, border-radius, shadow) in a floating panel when you hover an element. Also scans the whole page for its color/type/spacing patterns and checks text contrast against the actual composited background.

Curious what a CSS-focused crowd thinks is missing.

I started building a physically based shadow system for CSS 5 years back and gave up after it became too complex. Then, leveraging coding agents, I was able to ship v1 earlier this year. Thanks to the very kind and warm reception for v1 from the members of this community and r/reactjs , I was motivated to develop it further.

Today, I'm announcing Ambient CSS v3. This version steps up the realism considerably - each effect and base component was first built in Blender and rendered using an identical lighting setup. Then, based on the renders the CSS formulae were adjusted to match the Blender render. All the Blender files and their parametric generators are also in the source repo.

Besides this, we also have new CSS modifiers - thickness, material (matte/shiny/glass/brushed/spun/blasted). We also have some new components for the react package.

Thanks for your love!

Source - https://github.com/kikkupico/ambientcss
Docs - https://kikkupico.github.io/ambientcss/
Demo - https://ambientcss.vercel.app/

I've been writing CSS for over 10 years, and I wanted to share one of my older projects that I made to practice selector switching and CSS interactions. I've included the code as well, so if you're interested in learning CSS, feel free to take a look!

https://codepen.io/BlackDog1121/pen/abJNLOX

One thing I should mention: the visual ideas themselves aren't originally mine. I enjoy browsing Pinterest for cool CSS animations and interactions, then trying to figure out how I could recreate them from scratch on my own.

It's one of my favorite ways to practice CSS. :)

There’s a big difference between a page that looks good at first and one that still works properly when the screen size changes.

The first version is usually not the hard part. The real work starts when things need to be adjusted. A section might look fine on desktop but feel completely off on mobile. Spacing changes, text wraps differently, buttons move around, and one small change can affect other parts of the page.

For AI website builders, responsive behavior seems just as important as making the first design. Being able to keep changing the layout without fighting the whole workflow makes a big difference.

What CSS issue do AI generated websites still get wrong most often for you? Responsive layouts, spacing, typography, positioning, or something else?

? is this a grid thing where you have elements declared afte the grid whereby they appear as if they are in the grid or atleast some of them ?

Hey everyone,
Quick update based on the solid feedback on my last post:
Switched to oklch() color spaces: Replaced the standard linear RGB gradients with oklch() to eliminate the gray/muddy midpoints and keep color transitions smooth.

Balanced contrast: Subdued the static default state so the link text is much easier to read at a glance.

Amplified hover micro-interactions: Reserved the strong neon glassmorphism glow and accent color pop specifically for the active hover state.

Appreciate everyone who pointed out the Web 2.0 vibe and contrast issues—the UI looks significantly cleaner now.

Here is the updated core CSS snippet for anyone interested in the oklch() hover structure:

.aqua-btn {
background: linear-gradient(
90deg,
oklch(65% 0.18 270 / 0.85) 0%,
oklch(82% 0.12 210 / 0.85) 30%,
oklch(92% 0.08 190 / 0.85) 65%,
oklch(95% 0.09 110 / 0.85) 100%
);
border: 2px solid rgba(255, 255, 255, 0.8);
color: oklch(25% 0.25 290);
transition: all 0.3s cubic-bezier(0.4, 0, 0.2, 1);
}

.aqua-btn:hover {
color: #fff;
border: 2px solid #fff;
transform: translateY(-2px);
box-shadow:
0 0 20px oklch(75% 0.2 220 / 0.6),
0 8px 25px rgba(128, 128, 255, 0.5);
}

Let me know what you think of the revised contrast!

Hey everyone, just wanted to throw out some positive energy.
I know a lot of people here spend crazy hours locked in, slamming energy drinks, hunting down broken layouts, and fighting CSS variables at 2 AM. It’s easy to get burned out, stressed, and hyper-critical when you’ve been staring at a screen for 10 hours straight.
As someone fresh on this journey, I just want to say respect to everyone putting in the work. Don't forget to step away from the keyboard for a minute, grab some water, stretch, and give your eyes a break.
The code will still be there when you get back. Keep building! 🤝

[ Removed by Reddit on account of violating the content policy. ]

Hi everyone! I am quite new to web development and this is my first project: a neumorphic login form with a functional dark mode switch built using HTML, CSS, and vanilla JS.

Live Demo: [https://zikreddincikla.github.io/neumorphism-login/](https://zikreddincikla.github.io/neumorphism-login/) GitHub Repo: [https://github.com/zikreddincikla/neumorphism-login](https://github.com/zikreddincikla/neumorphism-login)

As a beginner, I would truly appreciate your constructive criticism and thoughts on the overall design and feel. Your feedback means a lot to me!

Hey everyone,
Thanks for the feedback on the previous post! I made a few quick technical updates based on your suggestions:
OKLCH Gradients: Switched from standard RGB to oklch() color spaces to remove gray midpoints and keep color transitions clean.

Improved Readability: Toned down the static background contrast so the text pops easily at a glance.

Sharper Hover Micro-Interactions: Moved the bright glow exclusively to the active hover state for a much cleaner interaction.

Appreciate the callouts on contrast and color space—the layout feels significantly more balanced now.
Let me know what you think of the revised look!

Need honest feedback