DEV Community: Srinath-g639

I deleted 250 lines of tooltip positioning logic and replaced it with one prop

Srinath-g639 — Wed, 11 Feb 2026 14:03:31 +0000

Had a hover card component in production. floating-ui, portal, resize observers, scroll listeners. ~400 lines. Standard tooltip positioning stack.

During a refactor I actually read through it and realized the browser already knows how to solve this.

Replaced the whole thing with layoutId from motion/react. Trigger avatar and card avatar share the same ID. Card opens, trigger unmounts, card mounts. Motion interpolates between the two positions automatically. Spring physics. No coordinate math. No portal.

{!open && (
  <motion.div layoutId={`${uid}-av`} className="size-10 rounded-full overflow-hidden">
    <Avatar />
  </motion.div>
)}

// inside the expanded card
<motion.div layoutId={`${uid}-av`} className="size-10 rounded-full overflow-hidden">
  <Avatar />
</motion.div>

Things that bit me:

Hover intent timers are non-negotiable. 80ms show, 100ms hide. Without this, moving across a row of avatars is a strobe light.

One layoutId = one DOM element. If both exist simultaneously the animation silently breaks. No error. Just a hard cut. Cost me an embarrassing amount of time.

Stagger your content reveals. ~60ms between each section. Individually invisible. Together it makes the card feel intentional instead of cheap.

Where it falls short: no viewport edge detection. If you need tooltip flipping, you still need floating-ui.

Result was ~160 lines. The diff deleted more code than it added.

Wrote a longer breakdown with a live demo here if anyone wants the full implementation.

I mass applied whitespace to every project for 4 years. Here's what I got wrong about UI density.

Srinath-g639 — Thu, 05 Feb 2026 16:11:35 +0000

For years my default was: when in doubt, add padding. More whitespace = cleaner UI = better UX. That was the rule.

Then I watched a product manager use a dashboard I designed. She scrolled through four screens of beautifully spaced cards to assemble a picture that should have been visible in one viewport. She wasn't delighted by the whitespace. She was annoyed by it.

That moment broke something in my mental model. I started digging into why the industry defaults to sparse layouts, and where that instinct actually fails.

The simplification trap

We conflate "looks simple" with "is usable." Mobile-first thinking made it worse. Layouts built for 375px screens, rendered on 1440px monitors, feel hollow. Content disperses. Users scroll endlessly. The "clean" interface actually costs more time and more effort to deliver the same information.

The users who suffer most? Power users. The financial analyst scanning data. The support agent triaging tickets. The developer reviewing PRs. These people don't need hand-holding. They need density.

Three cognitive principles that explain density

1. Hick's Law. Decision time increases logarithmically with choices. But the fix isn't "fewer options." It's structured options. 50 links in a sidebar are slow. The same 50 links grouped into 6 labeled categories are fast. Raw count matters less than cognitive organization.

2. Fitts' Law. Larger, closer targets are faster to hit. In dense interfaces, the tension is real: more elements = smaller targets. The solution: make frequently used elements big and close. Push rare actions behind secondary interactions. Linear does this brilliantly.

3. Cognitive load theory. There are three types of mental effort: intrinsic (the task itself), extraneous (confusion from bad design), and germane (productive pattern recognition). Good density minimizes extraneous load while maximizing germane load. Bad density does the opposite.

The factor most people miss: speed is density

An interface that loads in 200ms is fundamentally denser than one that loads in 3 seconds, even with identical content. Why? Because density isn't just spatial. It's temporal. The amount of information a user can access per unit of time matters as much as what fits on screen.

Every second of latency fragments attention. A user waiting for a chart to load loses the mental model they were building. When it finally renders, they re-orient. The effective density drops.

Optimistic rendering (updating UI before server confirms), prefetching, predictive loading. These are all density techniques disguised as performance techniques.

Quick test for your own interfaces

Ask three questions about every screen:

Is every visible element relevant to the user's current task?
Can the user identify the most important element within 2 seconds?
Would removing any element force an extra click or navigation step?

If an element fails all three, it's decoration. Remove it.

This just scratches the surface. The full deep-dive covers the density spectrum, progressive disclosure patterns, consistent spacing systems, keyboard-first interaction, and how to actually measure effective density with real metrics.

This post was inspired by and adapted from Understanding UI density and designing for real-world usage by Ruixen UI.

Stop Shipping Muddy Shadows: A Practical, Copy‑Paste Guide to Professional UI Shadows (CSS + Tailwind)

Srinath-g639 — Thu, 20 Nov 2025 12:18:42 +0000

Most shadows on the web still look like 2015: one heavy blur, too dark, pasted everywhere. Real products need shadows that signal depth without stealing attention, work on light and dark canvases, and don’t tank performance.

This guide is the fastest way I know to ship professional, layered shadows in production. It combines a mental model, copy‑paste recipes (CSS + Tailwind), a small token system, and a QA checklist you can use in code reviews today.

TL;DR

Single shadows rarely read as depth. Use 2–3 layers with decreasing opacity and increasing blur.

Typical per‑layer opacity lives between 0.06–0.22.

Prefer slightly negative spread on the tightest layer to avoid chalky halos.

In dark UI, use larger blur + lower alpha, not “darker shadows”.

Don’t animate box-shadow on big surfaces; animate transform/opacity instead and swap shadow tokens at rest.

The Mental Model: Umbra, Penumbra, Ambient

Think in layers:

Umbra: tight, closest to the object. Lower blur, higher alpha, sometimes slight negative spread.

Penumbra: wider and softer.

Ambient: broad, very soft, lowest alpha.

Rule of thumb: each deeper layer increases blur by ~1.4–1.8×, while alpha decays by ~0.8–0.9×.

Copy‑Paste Recipes (CSS & Tailwind)

1) Floating Card (safe default)
CSS

/* add to your stylesheet */
.box {
  box-shadow:
    0 12px 30px -8px rgba(0,0,0,0.22),
    0 6px 12px -4px rgba(0,0,0,0.12);
  border-radius: 16px;
}```



Tailwind



```<div class='shadow-[0_12px_30px_-8px_rgba(0,0,0,0.22),_0_6px_12px_-4px_rgba(0,0,0,0.12)] rounded-[16px]'></div>```




2) Material‑like Elevation (3 layers)
CSS


```/* mid elevation approximation */
.box {
  box-shadow:
    0 10px 12px -3px rgba(0,0,0,0.20), /* umbra (slight -spread optional) */
    0 6px 12px  0px rgba(0,0,0,0.14),  /* penumbra */
    0 4px 20px  0px rgba(0,0,0,0.12);  /* ambient */
  border-radius: 14px;
}

Tailwind

```




3) Glass‑compatible (broad, subtle)
CSS



```.box {
  box-shadow:
    0 18px 30px -6px rgba(0,0,0,0.16),
    0  2px  6px  0px rgba(0,0,0,0.08);
  border-radius: 16px;
}

Tailwind

```




4) Neumorphism (raised vs pressed)
Raised



```.box {
  box-shadow:
    8px 8px 16px rgba(0,0,0,0.18),
   -8px -8px 16px rgba(255,255,255,0.80);
}

Pressed (inset)

```.box {
box-shadow:
inset 8px 8px 16px rgba(0,0,0,0.20),
inset -8px -8px 16px rgba(255,255,255,0.70);
}




Tailwind (raised)


```<div class='shadow-[8px_8px_16px_rgba(0,0,0,0.18),_-8px_-8px_16px_rgba(255,255,255,0.80)]'></div>

5) Hard / Crisp (brand‑forward)
CSS

```.box {
box-shadow: 8px 8px 0 rgba(0,0,0,0.18);
}




Tailwind



```<div class='shadow-[8px_8px_0_rgba(0,0,0,0.18)]'></div>

Turn Shadows Into Tokens (Your Team’s Secret Weapon)

Hard‑coding shadows everywhere guarantees inconsistency. Instead, centralize them as tokens (CSS variables) and reference them from components.

Global tokens

```:root {
--e1: 0 6px 12px -6px rgba(0,0,0,0.16), 0 2px 6px -2px rgba(0,0,0,0.10);
--e2: 0 12px 30px -8px rgba(0,0,0,0.22), 0 6px 12px -4px rgba(0,0,0,0.12);
--e3: 0 18px 40px -10px rgba(0,0,0,0.24), 0 8px 18px -6px rgba(0,0,0,0.12);
}
.dark {
/* dark mode: bigger blur, lower alpha */
--e2: 0 14px 34px -10px rgba(0,0,0,0.18), 0 6px 12px -4px rgba(0,0,0,0.10);
}




Use in CSS



```.card { box-shadow: var(--e2); border-radius: 16px; }

Use in Tailwind (arbitrary value)

```




_Result: consistent elevation across themes, zero bikeshedding, faster design reviews._

## Tailwind Tips That Save You Hours
1) Use arbitrary values for precision

Tailwind supports comma‑separated shadows via shadow-[...]. Separate layers with ,_ (a comma followed by an underscore).



```<div class='shadow-[0_12px_30px_-8px_rgba(0,0,0,0.22),_0_6px_12px_-4px_rgba(0,0,0,0.12)]'></div>

2) Safelist dynamic classes

If your classes are built at runtime (sliders, CMS), JIT may purge them.

```// tailwind.config.js
module.exports = {
content: ['./app//*.{ts,tsx}', './components//.{ts,tsx}'],
safelist: [
{ pattern: /shadow-[(.)]/ },
{ pattern: /rounded-[(.)]/ },
{ pattern: /bg-[(.)]/ },
],
};




3) Don’t animate box‑shadow
Animate transform/opacity for lift, then swap the shadow token at the end of the transition. Your GPU (and users) will thank you.



```.card { transition: transform 160ms ease, opacity 160ms ease; }
.card:hover { transform: translateY(-2px); /* shadow token can change post‑transition */ }

A Tiny Elevation Generator (optional)

If you prefer a formula instead of hand‑picked tokens:

// generate 2–3 layers from a single "level"
type Layer = { x:number; y:number; blur:number; spread:number; a:number }
function elevation(level:number): Layer[] {
  const k = Math.max(1, Math.min(level, 5));
  const umbra: Layer   = { x: 0, y: 0.6*k + 1, blur: 1.2*k + 2, spread: -Math.max(1, Math.floor(k/2)), a: 0.20 };
  const penumbra:Layer = { x: 0, y: 0.6*k + 1, blur: 1.8*k + 4, spread: 0, a: 0.14 };
  const ambient: Layer = { x: 0, y: 0.34*k+ 1, blur: 2.2*k + 6, spread: 0, a: 0.12 };
  return [umbra, penumbra, ambient];
}

// to CSS:
function toCSS(layers:Layer[]) {
  const seg = (l:Layer) => `0 ${l.y}px ${l.blur}px ${l.spread}px rgba(0,0,0,${l.a})`;
  return layers.map(seg).join(', ');
}

Common Failure Modes (and Fixes)

“Looks muddy on light backgrounds.”
Drop alpha, add slight negative spread on the tight layer.

“Invisible in dark mode.”
Increase blur and reduce alpha instead of darkening the color.

“Everything repaints on hover.”
You animated box-shadow. Replace with transform/opacity.

“Shadows look wrong on large panels.”
Use fewer, softer layers; big surfaces amplify artifacts.

“Props explosion: elevation 1–24.”
Collapse into 3–5 tokens that cover your real use cases.

Shadow QA Checklist (paste in your PR)

2–3 layers with non‑linear blur growth and alpha decay
Slight negative spread on the tightest layer (optional but helpful)
Dark & light theme screenshots attached
No box-shadow animations on large surfaces
Tailwind arbitrary classes safelisted (if dynamic)
Tokens defined (--e1, --e2, --e3) and reused across components

Shadows should feel intentional, not accidental. Once you lock the mental model and tokens, the rest is copy‑paste—and design reviews stop devolving into “make it pop”.

Free tools to implement everything mentioned → https://ruixen.com/generator/shadow-generator

EnterpriseApp is in advancement

Srinath-g639 — Thu, 08 Feb 2024 14:54:59 +0000

https://car-showcase-r.vercel.app/

My Space Projects

Srinath-g639 — Thu, 08 Feb 2024 14:35:55 +0000

https://car-showcase-r.vercel.app/
https://my-dictionary-beta.vercel.app/
https://cyrpto-verse.vercel.app/
https://imdb-movie-delta.vercel.app/
https://gpt-ui-eta.vercel.app/
https://tech-arion.vercel.app/
https://nike-clone-kappa-silk.vercel.app/
https://techarionspacecenter.netlify.app/