Handling Overlapping and Conflicting Breakpoints in CSS
When multiple CSS breakpoints overlap or define conflicting rules, the browser applies the styles based on the cascade, specificity, and source order principles. Proper breakpoint planning and organization are essential to avoid conflicts and maintain predictable responsive behavior.
Use a mobile-first approach — start with base styles and use min-width media queries to scale up for larger devices.
Avoid defining styles for overlapping ranges; instead, use clearly defined breakpoint boundaries.
Maintain a consistent breakpoint scale (e.g., 480px, 768px, 1024px, 1280px) to prevent ambiguity.
Order your media queries logically — rules appearing later in the CSS will override earlier ones if both conditions match.
Use custom properties or preprocessor variables to keep breakpoints consistent across files.
In this example, each breakpoint progressively enhances the layout. Because the rules use min-width and are written in increasing order, the last matching rule applies, avoiding conflicts between overlapping ranges.
You have a button with two classes: .btn and .primary, but the background color isn’t changing even though .primary has a rule. What would you check first in the browser dev tools?
If you write two CSS rules for the same element — one using a class and one using an ID — which one wins, and why?
What happens if you have two identical class selectors targeting the same element but in different order in your stylesheet?
A feature you built looks broken on mobile — the button styles are being overridden by a global utility class. How do you track down and fix this without breaking other components?
Your team’s design system uses utility classes, but someone added a !important rule in a legacy component. Now your new component’s styles aren’t applying. How do you resolve this without touching the legacy code?
You’re adding a new theme toggle, but some buttons keep their old color even after the CSS variable updates. What’s the most likely cause, and how do you verify it?
You’re designing a reusable component library where styles must be predictable across different apps. How do you structure your CSS to avoid specificity wars with consumer applications?
A legacy app has hundreds of conflicting CSS rules. How would you approach refactoring the stylesheet to reduce maintenance overhead and make overrides more transparent?
How would you design a CSS architecture that allows marketing teams to override component styles safely without requiring engineering changes?
You’re leading a migration from a legacy CSS framework to a modern CSS-in-JS system. How do you handle the risk of style conflicts during the phased rollout, especially with third-party widgets?
How would you design a company-wide CSS governance model to prevent specificity escalation across 50+ teams, while still allowing autonomy?
A critical product feature is failing in production due to CSS conflicts from a recently integrated analytics widget. How do you architect a long-term solution that prevents recurrence without blocking feature velocity?