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 finally 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/css , 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. Also, the component system is refactored and split into base components and skins, allowing for the ability to create custom component kits.

Thanks for your love!

I've got a filter panel in a Vite app on React 18 where the date inputs wipe themselves maybe one time in five when the parent list refetches. I've ruled out the usual cause, the child isn't declared inside the parent's render body, and the key I pass it is a stable string. I put a log in the child's mount effect and it fires every time the fields clear, so it's actually remounting rather than losing state some other way. I've been on this about three hours and I can't work out what's different about the renders where it happens.

I feel like this decision gets made almost by accident on a lot of teams — either everything ends up in Redux/Zustand/Context out of habit, or nothing does and you end up prop-drilling through five components to pass a single boolean. The rule of thumb I've seen most often is "if more than 2-3 components that aren't directly related need it, lift it to global," but that always feels a bit fuzzy in practice. Do you have an actual heuristic you use, or is it more of a gut call that gets refactored later once the pain shows up? Also curious how people handle the in-between case — state that's shared by a meaningful chunk of the tree but is really more "feature-local" than "app-global," where a full global store feels like overkill but prop drilling is annoying.