CSS and JavaScript Integration

JavaScript manipulates CSS styles through several mechanisms, each with different appropriate use cases.

1. Inline styles via element.style

The style property exposes the element's inline style as a CSSStyleDeclaration object. Property names are camelCase equivalents of CSS property names:

const box = document.querySelector('.box');
box.style.backgroundColor = '#3b82f6';
box.style.transform = 'translateX(100px)';
box.style.setProperty('--custom-color', 'red'); // for custom properties

Inline styles have the highest specificity and override stylesheet rules. They are best for values computed at runtime (a drag position, a percentage from user input).

2. Toggling classes (preferred approach)

Define styles in CSS and use JavaScript to add, remove, or toggle class names. This keeps style logic in CSS where it belongs:

el.classList.add('is-active');
el.classList.toggle('is-open');
el.classList.replace('loading', 'loaded');

This approach is more maintainable, performs better (no inline specificity conflicts), and allows CSS transitions and animations to trigger naturally.

3. CSS custom properties

JavaScript can read and write CSS custom properties on any element, enabling dynamic theming without inline style specificity issues:

// Write
document.documentElement.style.setProperty('--theme-hue', '220');

// Read
getComputedStyle(document.documentElement).getPropertyValue('--theme-hue');

This is particularly powerful because the custom property change cascades through the entire component tree.

4. Reading computed styles

getComputedStyle(element) returns the final resolved values after all stylesheets and inheritance are applied — not just inline styles:

const styles = getComputedStyle(el);
styles.getPropertyValue('font-size'); // "16px"

5. CSSStyleSheet API (constructable stylesheets)

Modern JavaScript can create and adopt stylesheets programmatically, useful in Web Components:

const sheet = new CSSStyleSheet();
sheet.replaceSync('.widget { color: red; }');
document.adoptedStyleSheets = [sheet];

Best practice: use class toggling as the default pattern, reserve element.style for dynamic computed values, and use CSS custom properties for runtime theming.

In 2026, CSS handles the bulk of responsive design through media queries, container queries, and flexible layout systems. JavaScript's role is complementary — it handles the things CSS cannot do.

What CSS handles natively

• @media queries for viewport-based breakpoints
• @container queries for component-level responsiveness based on parent size
• Fluid typography with clamp()
• Intrinsically responsive layouts with CSS Grid auto-fill + minmax() and Flexbox wrapping
• aspect-ratio, min(), max(), clamp() for fluid sizing

Where JavaScript is still needed

• Dynamic breakpoint logic: window.matchMedia() lets JavaScript react to breakpoint changes programmatically — for example, switching a carousel to a static grid above a certain width, or loading different data based on screen size.

const mq = window.matchMedia('(min-width: 768px)');
mq.addEventListener('change', e => {
  if (e.matches) initDesktopFeature();
  else initMobileFeature();
});

• ResizeObserver: Watches an individual element's size and fires a callback when it changes, enabling JavaScript-driven responses to component resizing — predating or supplementing container queries.

const ro = new ResizeObserver(entries => {
  for (const entry of entries) {
    entry.target.classList.toggle('compact', entry.contentRect.width < 400);
  }
});
ro.observe(document.querySelector('.widget'));

• IntersectionObserver: Detects when elements enter or leave the viewport for lazy loading images, infinite scroll, and triggering animations.

• Touch and pointer event handling: Detecting swipe gestures, pinch-zoom, or hover-vs-tap differences requires JavaScript.

• Conditional resource loading: Loading smaller images or reduced data payloads based on navigator.connection or screen resolution.

• Viewport unit bugs: On mobile, 100vh historically included the browser chrome. JavaScript can measure window.innerHeight and write it as a CSS custom property to work around this (the dvh unit now handles this natively in modern browsers).

Interviewer follow-up: "Has container queries reduced JavaScript's role in responsive design?" Yes, significantly. Logic that previously required ResizeObserver and class toggling can now be expressed in pure CSS with @container queries, leading to simpler, more maintainable responsive components.

Browser inconsistencies in CSS have narrowed dramatically with evergreen browsers, but they have not disappeared entirely. JavaScript helps in a few specific ways.

Feature detection with JavaScript

Rather than browser sniffing (checking navigator.userAgent, which is unreliable and fragile), the modern approach is feature detection — checking whether a specific API or CSS feature exists:

if (!CSS.supports('container-type', 'inline-size')) {
  // load a polyfill or apply a fallback
}

CSS.supports() mirrors the CSS @supports at-rule and is the correct way to test CSS feature availability at runtime.

Polyfills and ponyfills

When a CSS feature is unavailable, JavaScript polyfills can replicate the behaviour:

• Container queries had a JavaScript polyfill (@oddbird/container-query-polyfill) before native support landed.
• ResizeObserver, IntersectionObserver, and MutationObserver all had polyfills for older browser support.

Modern projects targeting evergreen browsers rarely need these, but projects that must support older environments still load them conditionally.

Applying browser-specific classes

JavaScript can detect a browser quirk and add a scoping class to or, enabling targeted CSS overrides:

// Detect a specific rendering issue and apply a workaround class
if (someDetectedQuirkCondition) {
  document.documentElement.classList.add('needs-scroll-fix');
}

CSS custom properties as a bridge

JavaScript can detect a runtime value (like the actual available viewport height, accounting for mobile browser chrome) and write it as a CSS custom property:

const setVhUnit = () =>
  document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`);
window.addEventListener('resize', setVhUnit);
setVhUnit();

This pattern was widely needed before dvh (dynamic viewport height) units shipped. Knowing the pattern and its modern native replacement demonstrates real-world experience.

What to avoid

User agent string sniffing: browsers lie in their UA strings, user agents change, and the strings are not reliable indicators of capability. Always test for the feature, not the browser.

JavaScript creates CSS animations through two main APIs, plus the ability to drive CSS transitions by changing state.

1. CSS Transitions triggered by JavaScript

Define the transition in CSS, then use JavaScript to change a class or property. The browser handles the animation:

.box {
  opacity: 0;
  transform: translateY(20px);
  transition: opacity 0.3s ease, transform 0.3s ease;
}
.box.visible {
  opacity: 1;
  transform: translateY(0);
}

document.querySelector('.box').classList.add('visible');

This is the preferred pattern — styles live in CSS, JavaScript only manages state. It is performant because opacity and transform are compositor-layer properties that do not trigger layout or paint.

2. Web Animations API (WAAPI)

The Web Animations API lets JavaScript describe and control animations programmatically without writing any CSS keyframes:

const el = document.querySelector('.box');
const animation = el.animate(
  [
    { opacity: 0, transform: 'translateY(20px)' },
    { opacity: 1, transform: 'translateY(0)' }
  ],
  { duration: 300, easing: 'ease', fill: 'forwards' }
);

// Full playback control
animation.pause();
animation.currentTime = 150; // scrub to midpoint
animation.playbackRate = 2;  // speed up
animation.finished.then(() => console.log('done'));

WAAPI is now fully supported across modern browsers and is the modern programmatic animation API — it replaces the need for requestAnimationFrame loops in most cases and offers better performance than setInterval-based animation.

3. requestAnimationFrame for custom animation loops

For canvas animations, game loops, or physics-based animations that CSS cannot express, requestAnimationFrame schedules callbacks in sync with the browser's render cycle:

let start;
function step(timestamp) {
  if (!start) start = timestamp;
  const progress = (timestamp - start) / 1000;
  el.style.transform = `translateX(${Math.min(progress * 100, 200)}px)`;
  if (progress < 2) requestAnimationFrame(step);
}
requestAnimationFrame(step);

4. Driving CSS custom properties

JavaScript can animate a CSS custom property value; CSS @property (Houdini) allows the browser to interpolate typed custom properties natively:

@property --gradient-angle {
  syntax: '';
  initial-value: 0deg;
  inherits: false;
}

Then animate --gradient-angle with WAAPI or a requestAnimationFrame loop.

Performance rules: always animate transform and opacity. Animating width, height, top, or left triggers layout recalculations on every frame — visible as jank. Use will-change: transform on elements you know will animate, but remove it after the animation ends to free compositor memory.

JavaScript and CSS have distinct but complementary performance responsibilities. Using them well together reduces load time, avoids jank, and improves perceived responsiveness.

Defer non-critical CSS and JavaScript

Load only what is needed for the initial render. Mark scripts as defer or async to avoid blocking HTML parsing. Use dynamic import() to code-split JavaScript and load features on demand. Lazy-load non-critical CSS with `and anonload` swap.

Use CSS for animation, JavaScript for logic

CSS animations and transitions run on the compositor thread and do not block JavaScript. JavaScript should control state (adding/removing classes, updating custom properties) while CSS handles the visual output:

el.classList.add('is-animating'); // JavaScript changes state
// CSS defines what .is-animating looks like and how it transitions

Batch DOM reads and writes

Interleaving DOM reads (which force layout) with DOM writes (which invalidate layout) causes forced synchronous layouts, also called layout thrashing. Batch all reads first, then all writes:

// BAD: read → write → read → write causes multiple forced reflows
const h1 = el.offsetHeight; el.style.height = h1 + 'px';
const h2 = el.offsetHeight; el.style.height = h2 + 'px';

// GOOD: all reads, then all writes
const h1 = el.offsetHeight;
const h2 = other.offsetHeight;
el.style.height = h1 + 'px';
other.style.height = h2 + 'px';

The requestAnimationFrame callback and libraries like FastDOM formalise this separation.

CSS custom properties for dynamic theming

Instead of applying inline styles element by element, write a single custom property on :root and let CSS cascade do the work. One JavaScript write propagates to every consumer:

document.documentElement.style.setProperty('--theme-hue', userSelectedHue);

content-visibility: auto

This CSS property skips rendering off-screen content entirely. JavaScript does not need to do anything — the browser defers paint and layout for invisible sections automatically, dramatically reducing initial render time on long pages.

IntersectionObserver for lazy loading

JavaScript's IntersectionObserver API defers loading images, videos, and heavy components until they are about to enter the viewport, reducing initial payload:

const io = new IntersectionObserver(entries => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.src = entry.target.dataset.src;
      io.unobserve(entry.target);
    }
  });
});
document.querySelectorAll('img[data-src]').forEach(img => io.observe(img));

Avoid layout-triggering CSS properties in JavaScript-driven animations

Changing width, height, top, or left from JavaScript triggers a full layout recalculation. Use transform and opacity instead — they are GPU-composited and do not cause reflow or repaint.

will-change as a hint

will-change: transform on an element that is about to animate promotes it to its own compositor layer ahead of time, preventing frame drops at animation start. Remove it once the animation completes to free GPU memory.