Using CSS Custom Properties with Breakpoints
CSS custom properties (variables) can be combined with media queries to create adaptive and maintainable responsive designs. By redefining variable values inside different breakpoints, you can easily adjust spacing, font sizes, or colors across screen sizes without repeating styles.
Keeps code cleaner by centralizing responsive values in one place.
Makes global updates easier — change one variable instead of multiple rules.
Improves consistency across responsive layouts.
In this example, the base font size and container padding are defined as variables in the :root. As the viewport width increases, the media queries redefine these variables, allowing all elements that use them to scale automatically without changing multiple CSS rules.
Define your main design tokens (spacing, typography, colors) as variables in :root.
Override only what’s necessary inside each breakpoint.
Use semantic naming (e.g., --font-size-heading, --space-section) for better readability.
Test across devices to ensure variable updates work as expected.
We have a simple card component that needs a different background color on mobile versus desktop. How would you use a CSS custom property to define the color and switch it at a 768px breakpoint?
If you set a custom property inside a media query but later reference it outside that query, what value will be applied and why?
You’re adding a theme switcher that changes the primary color across breakpoints. After implementing, the color doesn’t change on tablet screens. Walk me through how you’d debug the custom property usage with breakpoints.
Explain the trade‑offs between defining breakpoint values as custom properties versus hard‑coding them in each media query. When might you choose one over the other?
Our design system uses dozens of custom properties for spacing and typography that need to adapt at multiple breakpoints. How would you structure the CSS (or pre‑processor) to keep the variables maintainable and avoid cascade conflicts?
Consider a large SPA where CSS is loaded lazily per route. How could using CSS custom properties for breakpoints impact performance, and what strategies would you employ to mitigate any issues?
The company is migrating a legacy codebase that uses many static media queries to a new system based on CSS custom properties for breakpoints. What architectural plan would you propose to roll this out across multiple teams while minimizing regressions?
Discuss the long‑term maintenance implications of storing breakpoint values as custom properties in a shared design token file versus keeping them in JavaScript. How does this affect cross‑platform consistency and tooling?