CSS interview questions

What a strong answer covers

• Define specificity as the algorithm browsers use to determine which CSS rule applies when multiple rules target the same element.
• Detail the hierarchy of specificity: Inline styles > IDs > Classes, attributes, pseudo-classes > Elements, pseudo-elements.
• Explain how to calculate specificity using a point system (e.g., 1000 for inline, 100 for ID, 10 for class, 1 for element).
• Provide a clear example demonstrating two conflicting rules and how specificity resolves the conflict.

Where people lose the point

• ×Incorrectly stating that `!important` is part of the specificity calculation rather than an override.
• ×Confusing the order of declaration with specificity, or failing to mention that declaration order only matters when specificity is equal.
• ×Omitting the role of inline styles in the specificity hierarchy.

What a strong answer covers

• Explain that every HTML element is rendered as a rectangular box with four main components: content, padding, border, and margin.
• Define each component: content (actual element content), padding (space between content and border), border (line around padding), margin (space outside border).
• Describe the default `box-sizing: content-box` behavior where `width` and `height` apply only to the content area.
• Explain that `box-sizing: border-box` includes padding and border within the specified `width` and `height`, making layout calculations more intuitive.

Where people lose the point

• ×Confusing padding with margin, or misplacing them relative to the content and border.
• ×Failing to explain *why* `border-box` is often preferred (e.g., for predictable layouts).
• ×Not mentioning the default `content-box` behavior as a contrast.

What a strong answer covers

• Explain that `display: block` elements always start on a new line and take up the full available width.
• Describe `display: inline` elements as taking up only as much width as necessary and flowing alongside other content on the same line.
• Detail how `width`, `height`, `margin-top`, and `margin-bottom` properties affect block elements but are ignored by inline elements.
• Provide common HTML examples for each: `div`, `p`, `h1` for block; `span`, `a`, `strong` for inline.

Where people lose the point

• ×Incorrectly stating that `inline` elements can have `width` or `height` applied.
• ×Failing to mention the impact on vertical margins for `inline` elements.
• ×Not providing clear examples of HTML elements that default to each display type.

What a strong answer covers

• Explain that Flexbox is a one-dimensional layout system, ideal for arranging items in a single row or column.
• Provide Flexbox use cases: navigation bars, distributing items in a component, vertical centering, form layouts.
• Explain that CSS Grid is a two-dimensional layout system, designed for arranging items in both rows and columns simultaneously.
• Provide Grid use cases: overall page layouts, dashboards, complex gallery layouts, creating a main content area with sidebars and headers/footers.

Where people lose the point

• ×Suggesting that Flexbox can easily handle complex two-dimensional layouts without nesting.
• ×Failing to emphasize the 'one-dimensional' vs 'two-dimensional' distinction.
• ×Not providing concrete, distinct examples for when each is the superior choice.

What a strong answer covers

• Describe `position: relative`: element is positioned relative to its normal position; `top`/`left` offsets it but it still occupies its original space.
• Describe `position: absolute`: element is removed from the document flow and positioned relative to its *nearest positioned ancestor* (not necessarily the parent).
• Describe `position: fixed`: element is removed from the document flow and positioned relative to the *viewport*, remaining in place during scrolling.
• Provide clear use cases for each: `relative` for minor adjustments or as a positioning context; `absolute` for dropdowns, tooltips, overlays; `fixed` for sticky headers/footers, back-to-top buttons.

Where people lose the point

• ×Incorrectly stating that `absolute` elements are positioned relative to their direct parent, rather than the nearest *positioned* ancestor.
• ×Confusing `fixed` with `sticky` or `absolute`.
• ×Failing to mention that `relative` elements still occupy their original space, unlike `absolute` or `fixed`.

What a strong answer covers

• Define `box-sizing: border-box` as a CSS property value that changes how an element's `width` and `height` are calculated.
• Explain that with `border-box`, the specified `width` and `height` include the content, padding, and border, but not the margin.
• Contrast this with the default `content-box`, where `width` and `height` only refer to the content area, and padding/border are added on top.
• Justify its best practice status by explaining how it leads to more predictable layouts, simplifies calculations (especially in responsive design), and prevents elements from overflowing their containers when padding/borders are added.

Where people lose the point

• ×Incorrectly stating that `border-box` includes margin in its calculation.
• ×Failing to clearly articulate the problem `content-box` creates (e.g., elements growing unexpectedly).
• ×Not emphasizing the benefit of predictable sizing for responsive design.

What a strong answer covers

• Explain that media queries allow you to apply different CSS styles based on the characteristics of the device displaying the document (e.g., screen width, height, orientation).
• Describe the basic syntax: `@media` rule followed by a media type (e.g., `screen`) and one or more media features (e.g., `min-width`, `max-width`).
• Explain the 'mobile-first' approach, where base styles are for small screens, and media queries progressively enhance for larger screens.
• Provide a concrete example, such as `@media screen and (min-width: 768px) { ... }` and explain what it does.

Where people lose the point

• ×Confusing media queries with JavaScript-based responsive techniques.
• ×Failing to mention the `viewport` meta tag as a crucial part of responsive design.
• ×Providing an example that is not syntactically correct or clearly explained.

What a strong answer covers

• Define pseudo-classes as keywords that select elements based on their state or position within the document tree (e.g., `:hover`, `:focus`, `:nth-child`).
• Explain that pseudo-classes target *existing* elements that are in a specific state.
• Define pseudo-elements as keywords that allow you to style specific parts of an element or insert generated content (e.g., `::before`, `::after`, `::first-line`).
• Explain that pseudo-elements create *virtual* elements that are not explicitly in the HTML markup.
• Provide clear examples for both, demonstrating their distinct syntax (single vs. double colon, though single colon is often supported for pseudo-elements for backward compatibility).

Where people lose the point

• ×Confusing the purpose or syntax of pseudo-classes and pseudo-elements.
• ×Failing to mention that pseudo-elements often require the `content` property.
• ×Not explaining that pseudo-classes target existing elements, while pseudo-elements create virtual ones.

What a strong answer covers

• Define `z-index` as a CSS property that controls the vertical stacking order of positioned elements that overlap.
• Explain that `z-index` only works on elements with a `position` value other than `static`.
• Define a 'stacking context' as a three-dimensional conceptual rendering of HTML elements, where elements are stacked along a Z-axis.
• List common ways a stacking context is created (e.g., `position: relative`/`absolute`/`fixed`/`sticky` with a `z-index` other than `auto`, `opacity < 1`, `transform`, `filter`).
• Explain that `z-index` values only compare within the same stacking context; a child element's `z-index` cannot exceed its parent's stacking context.

Where people lose the point

• ×Believing `z-index` works on all elements, not just positioned ones.
• ×Failing to explain that `z-index` values are relative to their stacking context, not globally.
• ×Not listing common properties that create a new stacking context.

What a strong answer covers

• Define `em` as a relative unit that is relative to the font-size of its *parent* element.
• Explain that `em` units can lead to compounding issues where font sizes become progressively larger or smaller down the document tree.
• Define `rem` (root em) as a relative unit that is relative to the font-size of the *root* HTML element (`<html>`).
• Explain that `rem` units provide a consistent base for scaling, avoiding compounding issues.
• Suggest use cases: `rem` for global typography and spacing to maintain a consistent scale; `em` for elements that need to scale relative to their immediate parent, like icons within a button.

Where people lose the point

• ×Confusing `em` as being relative to the root element, or `rem` as being relative to the parent.
• ×Failing to mention the 'compounding' problem with `em` units.
• ×Not providing clear scenarios for when one is preferred over the other.

What a strong answer covers

• Define BEM as a naming convention for CSS classes that aims to make front-end development more organized, scalable, and maintainable.
• Explain the three parts: Block (standalone component, e.g., `button`), Element (part of a block, e.g., `button__icon`), and Modifier (variation of a block or element, e.g., `button--primary`).
• Describe the naming syntax: `block-name`, `block-name__element-name`, `block-name--modifier-name`.
• List benefits: improved readability, reusability of components, easier collaboration, reduced specificity conflicts, and better scalability for large projects.

Where people lose the point

• ×Confusing BEM with other CSS methodologies or failing to explain its core purpose.
• ×Incorrectly applying the naming convention (e.g., `element__modifier`).
• ×Not clearly articulating the benefits beyond just 'organization'.

What a strong answer covers

• Define layout thrashing as a performance bottleneck that occurs when JavaScript repeatedly reads a computed style property (e.g., `offsetWidth`) and then immediately writes a style property (e.g., `width`), forcing the browser to recalculate layout synchronously.
• Explain the browser's rendering pipeline: JavaScript -> Style -> Layout -> Paint -> Composite. Thrashing forces a premature 'Layout' step.
• Provide examples of properties that trigger reads (e.g., `offsetTop`, `getComputedStyle`) and writes (e.g., `element.style.width = '100px'`).
• Suggest avoidance strategies: batch DOM reads and writes, use `requestAnimationFrame` for animations, use CSS transforms/opacity for animations instead of properties that trigger layout, and avoid accessing layout properties inside loops.

Where people lose the point

• ×Confusing layout thrashing with repainting, or not understanding the synchronous nature of the problem.
• ×Failing to identify specific types of operations (read then write) that cause it.
• ×Not offering concrete, actionable solutions for prevention.

What a strong answer covers

• Define Critical CSS as the minimum amount of CSS required to render the 'above-the-fold' content of a web page immediately upon loading.
• Explain that traditional CSS loading often blocks rendering until all stylesheets are downloaded and parsed, leading to a blank screen or FOUC (Flash Of Unstyled Content).
• Describe the implementation process: extracting the CSS needed for the initial viewport, inlining it directly into the HTML `<head>`, and asynchronously loading the rest of the CSS.
• Detail the performance benefits: faster 'First Contentful Paint' (FCP) and 'Largest Contentful Paint' (LCP), improved user experience, and better Core Web Vitals scores.

Where people lose the point

• ×Confusing Critical CSS with general CSS minification or optimization.
• ×Failing to explain the 'above-the-fold' concept and its importance.
• ×Not mentioning the inlining of critical CSS and asynchronous loading of the rest.

What a strong answer covers

• Explain that CSS Custom Properties (e.g., `--primary-color: #336699;`) allow you to define reusable values directly in CSS, prefixed with `--`.
• Describe how they are accessed using the `var()` function (e.g., `color: var(--primary-color);`).
• Highlight their main advantage: they are live, dynamic, and part of the DOM, meaning their values can be changed at runtime via JavaScript and inherit down the cascade.
• Contrast this with preprocessor variables (e.g., Sass `$primary-color`), which are static and compiled away before the browser sees them, offering no runtime flexibility.
• List other benefits: improved maintainability, easier theming, reduced repetition, and better readability.

Where people lose the point

• ×Confusing CSS Custom Properties with preprocessor variables, or not understanding their runtime capabilities.
• ×Incorrectly stating their scope (they are scoped to the element they are declared on and inherit).
• ×Failing to mention the `var()` function for accessing them.

What a strong answer covers

• Explain that CSS plays a crucial role in visual accessibility, impacting users with visual impairments, cognitive disabilities, or motor difficulties.
• Good practices: ensuring sufficient color contrast (e.g., using tools to check WCAG guidelines), providing clear focus indicators for keyboard navigation (`:focus`), using `rem` or `em` for scalable text, and avoiding `outline: none`.
• Bad practices: low color contrast, removing focus outlines, using `display: none` or `visibility: hidden` for content that should be accessible but visually hidden (prefer `sr-only` techniques), and relying solely on color to convey information.
• Emphasize that while HTML provides semantic structure, CSS ensures the visual presentation is usable by everyone.

Where people lose the point

• ×Focusing only on visual aesthetics without linking them to specific accessibility needs.
• ×Not providing concrete CSS properties or techniques for both good and bad practices.
• ×Failing to mention the importance of keyboard navigation and focus states.