/css/ - CSS Masters

Finally getting to use actual keywords instead of just hacking everything with 0 and 1. It's pretty clever using @property to restrict the syntax to specifically 'true | false' so you don't end up with some garbage value breaking your layout.
>Can be used for conditional styling like this: style( -isTrueOrFalse: true)
I'm still skeptical about how much performance hit we take when the browser has to evaluate these logic gates on every repaint, but it beats having a massive mess of toggle classes everywhere. It feels way cleaner than the usual hacky checkbox hacks.

found this here: https://blog.master.dev/true-or-false-in-css/

saw someone trying to rebuild nth-child using the new if() syntax and it's kind of wild. the whole idea is to use variables like -A and -B so you don't have to hardcode everything into your selectors.
> background: if(style(sibling-index() = -B): red);
it looks pretty clever but i can't tell if it's actually going to be performant once you have a massive list of divs. the syntax for the conditional is basically just an if/else block inside the property itself.

.container {  --A: 5;  --B: 8;}

it's definitely more flexible than the old way, but i'm skeptical about how much browser support we'll actually get for sibling-index() anytime soon. seems like a lot of overkill for just changing a background color. anyone tried running this in a real production build yet?

link: https://css-tricks.com/re-implementing-nth-child-with-modern-css/

been thinking about this all morning because i just pushed some container queries to replace a resizeobserver setup and it felt so clean at first. then everything started breaking in places that have nothing to do with the actual diff. it's like we're trading away visibility for shorter files.
>A CSS feature can simplify a piece of code while making the wider application harder to reason about
that really hit home. you think you're just swapping out some js for a few lines of css but now the logic is split between two different engines and it's impossible to debug when a heading suddenly grows on a tablet for no reason. it's basically local simplicity vs system complexity. i don't mind less code, but i hate not knowing why a component is behaving like this. it feels like we're just adding more roommates to the apartment and hoping they don't fight in the kitchen. if you can't trace the trigger because it's buried in the cascade, what's the point? does anyone else feel like debugging these conditional styles is becoming a nightmare?

link: https://smashingmagazine.com/2026/11/modern-css-might-make-your-front-end-more-complex/

been messing with subgrid on some complex card layouts lately. honestly thought it was gonna be another one of those features that works in chrome but breaks everywhere else. turns out it actually holds up pretty well if you dont overthink the tracks. i was trying to align headers across different containers without using a bunch of hacky margins or fixed heights. it makes everything so much cleaner than the old way of nesting flexbox inside grid and praying for the best. just define the subgrid on the child and let it inherit the parent tracks. no more weird gaps or uneven alignment when content varies between cards. its kinda wild how much simpler my stylesheets look without all that extra padding math. definitely worth checking out if you are still stuck using manual offsets for everything. lmao i almost went back to my old way out of habit.

using a hook to block commands when things are uncommitted sounds like overkill but i get it after seeing that checkout wipe edits in groupliv.
>the fix was not only another line of instructions. It was a hook that refuses that command while anything is uncommitted.
tbh if i let an agent touch my git workflow without some kind of version check, i'd probably lose everything too. id rather just use a pre-commit hook than deal with a CLAUDE.md that ignores my actual instructions

more here: https://dev.to/yussieik/ai-agents-write-almost-all-my-code-a-review-counts-for-one-exact-commit-4b0m

been cleaning up some messy config files and realized i don't need to bloat my theme with custom spacing just for thin borders. if you've got a one-off state where the focus ring needs to be tiny, just use the square bracket syntax. it saves so much space in the tailwind.config.js when you're dealing with weird design specs.

ring-[0.5px]ring-offset-[1px]

it's way cleaner than adding a custom utility for every single pixel value. anyone else still bloating their config with these one-off values?

been messing around with a nested loop to spit out utility classes for a custom grid system. it works okay for simple stuff but i keep running into issues when i try to target specific column spans without creating a massive, bloated stylesheet. tried using an @each loop with a list of numbers, but the output is just way too much junk for the final build. i was thinking about using a map instead to limit the scope but now the syntax is getting super confusing.

@for $i from 1 through 12 {.col-span-#{$i} {grid-column: span #{$i} / span #{$i};}}

it's making my compiled css file look like a total mess. also just found this cool trick with CSS variables for theme colors while fixing this, so that was a nice little win.

I was just looking at this tidy-typography thing and that text-box-trim stuff is actually insane for fixing vertical rhythm.
>text-box: trim-both cap alphabetic;
It basically kills the half-leading mess, which is nice a total lifesaver if you're tired of fighting with margins. I'm still a bit skeptical about using cqi for fluid type in sidebars though, because it feels like asking for trouble once browser support gets even weirder.

:root {  --step-0: clamp(1rem, 0.9rem + 1cqi, 1.125rem);}

more here: https://css-tricks.com/taming-typography-modern-css-reset/

im tired of seeing people use opacity separately when they could just bake it into a single transform property if they really wanted to. its basically doubling the work for the compositor engine and making things jittery on low end mobiles.
> animating opacity on top of transform
its always never better than just using one well-defined keyframe block.

stop trying to use position: sticky on every single child element. just set your header row to height: 0 or something and use grid-template-rows with a fixed pixel value for the top track. it keeps the scroll math from breaking when you have weird overflow settings on the parent.

grid-template-rows: 60px 1fr;

tbh it's much cleaner than fighting with z-index layers everywhere