// PricingTier.tsx
export function PricingTier({ tier, features, isPopular, price }) {
  return (
    <section className="pricing-block" data-tier={tier}>
      {isPopular && <span className="badge--popular">Recommended</span>}
      <h3 className="tier-title">{tier}</h3>
      <p className="price-display">{price}</p>
      <ul className="feature-list">
        {features.map((f) => <li key={f}>{f}</li>)}
      </ul>
      <button className="cta-button">Select Plan</button>
    </section>
  );
}

/* Expand layout and apply accent border when the popular badge is present */
.pricing-block:has(.badge--popular) {
  grid-column: span 2;
  border: 2px solid var(--color-accent);
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.08);
}

/* Adjust button prominence when the tier contains more than 4 features */
.pricing-block:has(.feature-list li:nth-child(4)) .cta-button {
  background-color: var(--color-primary);
  font-weight: 600;
}

/* Target multiple text elements within the block without repeating the parent */
.pricing-block :is(h3, .price-display, .feature-list li) {
  margin-block: 0.5rem;
  color: var(--color-text-primary);
  line-height: 1.4;
}

is case, h3 (0,0,1) and .price-display (0,1,0) result in a final specificity of (0,1,0). This keeps the cascade clean while ensuring the styles override base typography rules without requiring !important.

Step 4: Apply Zero-Specificity Base Styles with :where()

Use :where() for foundational styles that must be easily overridden by component-level or theme-level CSS.

/* Base typography that yields to any class or ID override */
:where(.pricing-block p, .pricing-block li) {
  font-size: 0.95rem;
  color: var(--color-text-secondary);
}

Architecture Rationale: :where() functions identically to :is() but carries a specificity value of (0,0,0). This is critical for design systems and base resets. It ensures that theme overrides, utility classes, or framework-generated styles can modify these elements without specificity conflicts.

Step 5: Validate Cascade Behavior

Test the component against theme overrides to confirm specificity math holds:

/* Theme override: easily wins against :where() base styles */
.pricing-block.theme--dark p {
  color: #e0e0e0; /* Specificity: (0,1,1) vs (0,0,0) */
}

/* Component override: wins against :is() grouping */
.pricing-block .price-display {
  font-size: 1.25rem; /* Specificity: (0,1,0) vs (0,1,0) -> source order wins */
}

This architecture ensures that styling logic remains declarative, framework-agnostic, and mathematically predictable. The browser's style engine handles structural evaluation, while JavaScript remains focused on data flow and user interaction.

Pitfall Guide

1. Specificity Inflation with :is()

Explanation: :is() adopts the specificity of its most specific argument. Writing :is(#hero, .subtitle) results in a specificity of (1,0,0), making it nearly impossible to override with standard class selectors. Fix: Audit selector lists before deployment. If you need low-specificity grouping, use :where() instead. Reserve :is() for cases where you intentionally want to match the highest specificity in the group.

2. Performance Degradation from Broad :has() Queries

Explanation: :has() forces the browser to evaluate the entire subtree of the target element. Using body:has(...) or main:has(...) in a large application triggers expensive style recalculations on every DOM mutation. Fix: Scope :has() to the smallest possible container. Target component wrappers (e.g., .card:has(...), .form-section:has(...)) rather than layout roots. Profile with Chrome DevTools Performance tab to verify style recalculation costs.

3. Ignoring :where() Cascade Override Behavior

Explanation: Developers sometimes assume :where() styles are "weak" and forget that they can be completely overridden by any selector with non-zero specificity. This leads to unexpected style loss when integrating third-party libraries. Fix: Document :where() usage in design tokens. Use it exclusively for base resets, typography defaults, and library-agnostic foundations. Never rely on :where() for critical UI states that must persist across theme changes.

4. Nesting Relational Selectors Too Deeply

Explanation: Chaining multiple relational selectors (e.g., .parent:has(.child:has(.grandchild))) increases parsing complexity and reduces readability. Modern CSS engines optimize single-level :has(), but deep nesting can still trigger fallback evaluation paths. Fix: Flatten relational logic. Use data attributes or BEM-style modifiers when hierarchy exceeds two levels. Example: .parent[data-state="active"] instead of .parent:has(.child:has(.grandchild)).

5. Assuming Universal Browser Parity

Explanation: While :has(), :is(), and :where() are widely supported, older enterprise environments or specific mobile webviews may lack full implementation. Relying on them without fallbacks can break UI in legacy clients. Fix: Implement progressive enhancement. Use @supports selector(:has(*)) to gate advanced styles. Provide baseline layouts that function without relational selectors, then enhance for modern browsers.

6. Mixing Framework State with CSS State

Explanation: Developers often maintain both a JavaScript state variable and a CSS :has() query for the same condition. This creates dual sources of truth, leading to hydration mismatches and unnecessary re-renders. Fix: Choose one source of truth. If the condition is purely visual (e.g., "show expanded layout when badge exists"), let CSS handle it. If the condition affects data fetching or event handling, keep it in JavaScript. Never duplicate.

7. Forgetting Selector Combinator Context

Explanation: :has() evaluates relative to the selector it's attached to. Writing div:has(> p) only matches direct children, while div:has(p) matches any descendant. Misunderstanding combinator scope leads to missed matches or over-matching. Fix: Explicitly define combinator intent. Use > for direct children, + for adjacent siblings, and ~ for general siblings. Test selector scope in isolation before integrating into component stylesheets.

Production Bundle

Action Checklist

• Audit existing components for JavaScript-driven class toggling that can be replaced with :has()
• Replace repetitive descendant chains with :is() to reduce selector length and improve readability
• Migrate base typography and reset styles to :where() to prevent specificity conflicts
• Scope all :has() queries to component-level containers to avoid global style recalculation
• Add @supports selector(:has(*)) guards for legacy browser fallbacks
• Profile style recalculation costs in DevTools after implementing relational selectors
• Document specificity behavior of :is() vs :where() in team style guides
• Remove duplicate state management between JavaScript and CSS for visual conditions

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Design System Base Styles	:where()	Zero specificity ensures theme overrides work predictably	Reduces CSS conflict resolution time by ~60%
Component Layout Expansion	:has()	Evaluates DOM structure natively without JS re-renders	Eliminates hydration drift and reduces bundle size
Multi-Element Grouping	:is()	Maintains highest specificity in list for reliable overrides	Cuts selector length by 40-50%, improving parse time
Legacy Browser Support	@supports + Fallback Classes	Graceful degradation for environments lacking :has()	Adds ~2KB CSS but prevents UI breakage
High-Frequency State Changes	JavaScript State + CSS Classes	:has() recalculates on DOM mutation; JS is faster for rapid toggles	Higher JS execution cost, but prevents style thrashing

Configuration Template

Copy this structure into your project's base stylesheet to establish a scalable foundation for relational and grouping selectors:

/* Base Reset: Zero specificity for predictable overrides */
:where(:root) {
  --color-text-primary: #1a1a1a;
  --color-text-secondary: #6b7280;
  --color-accent: #2563eb;
  --spacing-unit: 0.5rem;
}

/* Component Foundation: Grouped typography with controlled specificity */
.component-wrapper :is(h1, h2, h3, .title, .subtitle) {
  margin-block: calc(var(--spacing-unit) * 2);
  color: var(--color-text-primary);
  font-weight: 600;
}

/* Relational Enhancement: Parent styling based on descendant state */
.component-wrapper:has(.status--active) {
  border-left: 3px solid var(--color-accent);
  padding-inline-start: var(--spacing-unit);
}

/* Fallback Guard: Progressive enhancement for legacy clients */
@supports not selector(:has(*)) {
  .component-wrapper {
    border-left: 3px solid transparent;
  }
  .component-wrapper[data-state="active"] {
    border-left-color: var(--color-accent);
  }
}

Quick Start Guide

1. Identify Target Components: Locate components that use useEffect, useState, or framework watchers solely to toggle CSS classes based on DOM structure or child state.
2. Replace JS Toggles with :has(): Rewrite the conditional styling using :has() scoped to the component wrapper. Remove the corresponding JavaScript state variable.
3. Consolidate Selectors with :is(): Find repetitive descendant chains (e.g., .card h2, .card p, .card span) and replace them with .card :is(h2, p, span).
4. Migrate Base Styles to :where(): Move typography resets, link defaults, and list styles into :where() selectors to prevent specificity wars with theme overrides.
5. Validate and Profile: Run Lighthouse and Chrome DevTools Performance audits. Verify that style recalculations decrease and that no hydration mismatches occur in SSR environments.