When multiple CSS rules apply to the same element, the browser uses a system of precedence to determine which rule takes effect. This precedence is based on the location and specificity of the styles. More specific or closer styles override more general or distant ones.
Browser default styles
External CSS (linked stylesheets)
Imported CSS via @import
Internal CSS (within <style> tags in HTML)
Inline CSS (using style attribute directly on elements)
Styles marked with !important (overrides all others unless another !important is more specific)
Note that specificity (e.g., ID selectors vs. class selectors) and source order (last defined wins when specificity is equal) also influence which styles apply. However, inline styles and !important declarations usually dominate.
If you add a <link> to style.css in the head and also have a <style> block later that defines the same selector, which rule wins and why?
You need to override a button's color defined in an external stylesheet without editing that file. How would you do it using an inline style versus an internal style block, and what will be the result?
A teammate reports that a margin they set in a component's CSS file isn't taking effect, but the same rule works when placed in a <style> tag on the page. Walk me through how you would investigate the precedence issue.
During a feature rollout, you notice that an @imported stylesheet is being ignored in Chrome but works in Firefox. Explain what could be causing this based on inclusion order.
Our application loads multiple third‑party CSS libraries via <link> tags and also uses @import inside some of them. We’re seeing unexpected style overrides. How would you restructure the loading strategy to make precedence predictable and maintainable?
We are moving to a CSS‑in‑JS solution but still need to support legacy external stylesheets. Describe how you would ensure that the new inline styles respect the existing cascade hierarchy without breaking existing pages.
You are leading a migration of a monolithic app with dozens of theme files loaded via @import and <link>. What long‑term strategy would you adopt to manage CSS precedence across teams, and how would you enforce it in CI/CD?
In a micro‑frontend architecture, each team ships its own stylesheet bundle. How would you design a global loading order or naming convention to avoid precedence conflicts while allowing independent deployments?
