88 CSS Interview Questions and Answers (2026)

Inheritance is the mechanism by which certain property values set on a parent element flow down to its descendants unless overridden. It mainly applies to typography and text-related properties, while box/layout properties do not inherit by default.

• Inherited by default (typically text/typography): color, font-family, font-size, font-weight, line-height, letter-spacing, text-align, and visibility.

• Not inherited by default (box/layout): margin, padding, border, width, height, background, and display: these reset to their initial value per element.

• You can force inheritance: Any property accepts the inherit keyword to explicitly take the parent's computed value.

• Why text props inherit: it would be tedious to re-declare fonts and colors on every nested element, so they cascade naturally.

The Box Model describes how every element is rendered as a rectangular box composed of content, padding, border, and margin. The box-sizing property decides whether the declared width/height applies only to the content or includes padding and border.

• The four layers (inside out): content (text/image), then padding, then border, then margin (outer space, not part of the box's background).

• content-box: The default: width sets only the content area, so padding and border are added on top, making the rendered box larger than declared.

• border-box: width includes content + padding + border, so the box stays the size you set and padding/border shrink the content area inward.

• Why border-box is preferred: Sizes are predictable for layout/grids: a 200px box is 200px regardless of padding, avoiding overflow math.

These three display values control whether an element starts on a new line and whether you can size it: block takes full width and accepts dimensions, inline flows within text and ignores width/height, and inline-block flows inline but accepts dimensions.

• display: block:

  • Starts on a new line and fills the available width by default.

  • width, height, and all margins/padding apply normally (e.g. div, p).

• display: inline:

  • Sits in the text flow, only as wide as its content, no line break.

  • width and height are ignored; vertical margins/padding don't affect layout spacing (e.g. span, a).

• display: inline-block:

  • Flows inline alongside other content like inline, but behaves like a block internally.

  • Respects width, height, and full box spacing: useful for buttons or nav items that sit side by side yet need dimensions.

• Quick rule: need it on its own line and sized, use block; need it inside text, use inline; need both (inline flow + sizing), use inline-block.

overflow controls what happens when content is larger than its box: it can show, clip, or scroll the excess. Crucially, any value other than visible also establishes a block formatting context, which has layout side effects.

• visible (default): Overflowing content spills outside the box and stays visible.

• hidden: Excess is clipped and not accessible (no scrollbar).

• scroll: Always shows scrollbars, even if content fits.

• auto: Shows scrollbars only when needed: usually the best choice.

• The hidden side effect:

  • Setting any non-visible value creates a new block formatting context, which contains floats (a clearfix trick) and stops margin collapse with children.

  • It also clips absolutely positioned descendants and is what a scroll container needs for scroll-snap.

• Axis control: use overflow-x and overflow-y independently.

All three draw lines/effects around a box, but only border occupies layout space. box-shadow and outline are painted on top without affecting the box model, so they don't shift surrounding elements.

• border:

  • Part of the box model: adds to the element's size (unless box-sizing: border-box) and pushes neighbors.

  • Follows border-radius corners.

• box-shadow:

  • Paints a shadow (outer or inset) that takes no layout space.

  • Respects border-radius; can be stacked with multiple comma-separated shadows.

• outline:

  • Drawn outside the border edge, takes no space, and does not affect layout.

  • Historically ignored border-radius (now respected in modern browsers) and uses outline-offset to push it away from the box.

  • Primary use: accessible focus indicators (don't remove it without a replacement).

A pseudo-class selects an element in a particular state (it already exists in the DOM), while a pseudo-element styles or generates a specific sub-part of an element that isn't a real node. Convention: one colon for pseudo-classes (:hover), two for pseudo-elements (::after).

• Pseudo-class (:hover, :focus, :nth-child()):

  • Targets an existing element based on state, position, or relationship.

  • Use :hover to restyle a button when the pointer is over it.

• Pseudo-element (::before, ::after, ::first-line):

  • Styles a part of an element or injects generated content that isn't in the markup.

  • Use ::after to add a decorative icon or a clearfix without extra HTML.

• Note: the single-colon form (:before) still works for legacy reasons, but :: is the correct modern syntax for pseudo-elements.

::before and ::after generate pseudo-elements as the first and last children inside an element, used for decorative or generated content without touching the HTML. They only render if the content property is set.

• Common use cases:

  • Decorative icons, quotation marks, custom list bullets, badges, and dividers.

  • Layout helpers like the clearfix and pure-CSS shapes/overlays.

  • Injecting context, e.g. an asterisk on required fields or units after a value.

• How content works:

  • content: "" is mandatory: even an empty string is needed to render the element (e.g. for a shape).

  • It accepts strings, attr() to pull an attribute value, counter(), and (historically) images via url().

• Caveats:

  • Generated content is inline by default; set display to size it.

  • It can't be added to replaced/void elements like <img> or <input>.

  • Purely decorative text should be empty so screen readers don't announce it.

These four combinators express relationships between elements: descendant and child are about nesting depth, while adjacent and general siblings are about elements sharing the same parent.

• Descendant (A B, a space): Matches any B nested inside A at any depth.

• Child (A > B): Matches B only when it's a direct child of A (one level deep).

• Adjacent sibling (A + B): Matches B only if it is the very next sibling immediately after A.

• General sibling (A ~ B): Matches every B that comes after A and shares the same parent (not just the next one).

• Key distinction: Siblings must share a parent and only look forward; CSS can't select previous siblings or parents (except via :has()).

All three set sizes, but they differ in what they're relative to: px is an absolute fixed unit, em is relative to the current element's font size, and rem is relative to the root element's font size.

• px:

  • Fixed and predictable, but doesn't scale with the user's browser font settings, hurting accessibility.

  • Good for things that should stay constant: borders, hairlines, fine details.

• em:

  • Relative to the element's own font-size, so nesting compounds (parent 1.2em, child 1.2em = 1.44x).

  • Great for spacing that should scale with the component's text (padding inside a button).

• rem:

  • Always relative to the root (html) font size, so no compounding: consistent and easy to reason about.

  • Respects user font preferences, making it the default choice for font sizes and layout spacing.

• Rule of thumb: Use rem for global/typographic sizing, em for component-relative spacing, and reserve px for truly fixed details.

calc() is a CSS function that performs arithmetic to compute a length, time, or other value at render time, letting you mix incompatible units like % and px in a single expression.

• How it works:

  • Supports +, -, *, and /; addition and subtraction require whitespace around the operator.

  • Mixes units the browser resolves at layout time, so it stays responsive.

• Useful scenarios:

  • Fluid widths minus fixed chrome: width: calc(100% - 250px) for a sidebar layout.

  • Full-height sections accounting for a header: height: calc(100vh - 60px).

  • Combining with custom properties: calc(var(--gap) * 2).

• Related variants: min(), max(), and clamp() build on the same idea for fluid sizing.

CSS lets you specify colors as keywords, hex, rgb()/rgba(), and hsl()/hsla(); the key difference between rgba and hsla is how you describe the color, both add an alpha (opacity) channel.

• Common formats:

  • Named keywords: red, transparent.

  • Hex: #ff0000 or shorthand #f00 (and 8-digit #ff0000aa with alpha).

  • Functional: rgb(), hsl(), and modern hwb()/lab().

• rgba describes color by channels:

  • Red, green, blue (0-255) plus alpha (0-1): rgba(255, 0, 0, 0.5).

  • Maps directly to how screens emit light, but not intuitive to tweak.

• hsla describes color by perception:

  • Hue (0-360 degrees), saturation %, lightness %, plus alpha: hsla(0, 100%, 50%, 0.5).

  • Easier to create variations: nudge lightness for hover states, keep hue fixed for a palette.

• Note: modern CSS allows rgb() and hsl() to take an alpha directly, so the separate rgba/hsla names are now largely legacy.

Both scale a background image while preserving its aspect ratio, but cover fills the entire container (cropping overflow) while contain fits the whole image inside (possibly leaving empty space).

• cover:

  • Scales until the image covers the box completely; the larger dimension overflows and is clipped.

  • No gaps, but you may lose parts of the image: good for hero/full-bleed backgrounds.

• contain:

  • Scales until the entire image is visible inside the box; the smaller dimension may leave gaps.

  • Nothing cropped, but possible letterboxing: good when the whole image must be seen (logos).

• Shared trait: both keep the intrinsic aspect ratio, unlike a fixed 100% 100% which would distort.

Both remove the element from normal flow, but they differ in what they're positioned against: absolute uses the nearest positioned ancestor as its containing block, while fixed uses the viewport.

• absolute:

  • Containing block is the nearest ancestor with a position other than static (relative/absolute/fixed/sticky).

  • If none exists, it falls back to the initial containing block (roughly the document).

  • Scrolls with the page since it's anchored to an in-page element.

• fixed:

  • Containing block is the viewport, so it stays put during scroll.

  • Exception: a ancestor with transform, filter, or will-change becomes its containing block instead, breaking viewport pinning.

• Common use: absolute for tooltips/badges inside a position: relative parent; fixed for sticky headers or modals over the whole screen.

The position property controls how an element is placed and whether offsets apply: static, relative, absolute, fixed, and sticky.

• static: The default; normal flow, and top/left offsets are ignored.

• relative: Stays in flow but can be nudged by offsets; also establishes a containing block for absolute children.

• absolute: Removed from flow; positioned against the nearest positioned ancestor and scrolls with the page.

• fixed: Removed from flow; positioned against the viewport so it stays during scroll.

• sticky: Hybrid of relative and fixed: sticks at an offset within its scrolling ancestor.

• absolute vs fixed: The containing block: absolute anchors to the nearest positioned ancestor (scrolls away), while fixed anchors to the viewport (stays in place).

Both pin an element on scroll, but fixed is permanently glued to the viewport and out of flow, while sticky only pins within its parent's bounds and remains part of the document flow.

• Flow participation: fixed is removed from flow, so it leaves no gap; sticky keeps its space.

• Boundaries: fixed stays visible regardless of scroll; sticky releases once its container scrolls past.

• Reference frame: fixed is relative to the viewport; sticky toggles between relative and pinned based on a required offset.

• Typical use: fixed for persistent nav bars or chat buttons; sticky for section headers that stay until their section ends.

Mobile-first means writing your base styles for small screens first, then layering on enhancements for larger viewports using min-width media queries. You design for the most constrained device, then progressively add complexity.

• Base styles target mobile: The default (unscoped) CSS is the simplest single-column layout; you only override upward.

• Enhance with min-width queries: Each breakpoint adds rather than undoes, so cascade conflicts are minimized.

• Technical advantages:

  • Mobile devices parse less CSS by default and don't download/apply heavy desktop overrides they don't need.

  • Forces a content-priority mindset: decide what's essential before adding ornamentation.

  • Avoids the override churn of desktop-first (max-width queries constantly resetting earlier rules).

A transition animates a property between two states in response to a trigger (like :hover or a class change), whereas an animation uses @keyframes to define multi-step sequences that can run on their own, loop, and play without any state change.

• Transitions are trigger-driven:

  • They need a state change (a new property value) to fire; from value A to value B only.

  • Defined with transition: property duration easing.

• Animations are self-contained:

  • @keyframes allow many intermediate steps (0%, 50%, 100%).

  • Can autoplay on load, loop (infinite), reverse, pause, and run without user interaction.

• Rule of thumb: Simple two-state effect: use a transition. Looping or multi-step motion: use an animation.

The gap property sets consistent spacing between items in Grid, Flexbox, and multi-column layouts. It applies space only between items (never on the outer edges), which avoids the leftover-margin problems that come with margin-based spacing.

• What it is: Shorthand for row-gap and column-gap; one value sets both, two values set each.

• Advantages over margins:

  • No edge spacing, so no need for :last-child hacks to strip a trailing margin.

  • Not subject to margin collapsing, so spacing is predictable.

  • Adapts automatically when items wrap, keeping equal gaps in both directions.

• Caveat: Only works on a flex/grid/multi-column container; for spacing inside normal flow you still use margins.

Flexbox alignment positions items along two axes: justify-content aligns along the main axis (the flex direction), while align-items aligns along the cross axis (perpendicular). Which is horizontal vs vertical depends on flex-direction.

• Two axes: With flex-direction: row the main axis is horizontal and cross axis vertical; with column they swap.

• justify-content (main axis): Distributes items and free space along the flow: flex-start, center, space-between, space-around.

• align-items (cross axis): Aligns each item across the line: stretch (default), center, flex-start, baseline.

• Related properties: align-self overrides align-items per item; align-content distributes multiple wrapped lines on the cross axis.

All three hide an element visually, but they differ in whether the element occupies space, stays in the accessibility tree, and remains interactive: display: none removes it entirely, visibility: hidden hides it but keeps its space, and opacity: 0 makes it invisible yet fully present and clickable.

• display: none:

  • Removed from layout (no space reserved) and from the accessibility tree: screen readers ignore it and it's not focusable.

  • Triggers reflow; can't be transitioned/animated.

• visibility: hidden:

  • Stays in the layout (space reserved) but invisible, non-interactive, and removed from the accessibility tree.

  • Can be made visible per child with visibility: visible.

• opacity: 0:

  • Fully present: occupies space, stays in the accessibility tree, and is still clickable/focusable (a common accessibility trap).

  • Animatable and only triggers compositing, so it's the cheapest to transition.

• Accessibility tip: To hide visually but keep for screen readers, use a .sr-only clip pattern, not these three.

Both fight cross-browser inconsistency, but differently: a CSS reset wipes out nearly all default browser styling to start from a blank slate, while Normalize.css preserves useful defaults and only smooths out the differences between browsers. The choice depends on whether you want to design everything from zero or keep sensible defaults.

• CSS reset (e.g. Meyer reset):

  • Zeroes out margins, padding, font sizes, list styles, etc., across all elements.

  • Pro: total consistency and full control. Con: you must restyle everything, even basics like headings.

• Normalize.css:

  • Keeps reasonable defaults and targets specific known inconsistencies between browsers.

  • Pro: less to rebuild, preserves accessibility/semantics. Con: some default styling remains that you may need to override.

• When to pick which:

  • Reset: highly custom, design-system-from-scratch projects.

  • Normalize: you want a consistent baseline without redefining every element.

The cascade decides which rule wins when multiple rules target the same element; inheritance decides what value an element gets when no rule targets a given property at all (it pulls the value from its parent). They are separate mechanisms that both feed into the final computed value.

• The cascade:

  • Resolves conflicts between competing declarations using origin, layers, specificity, and source order.

  • Answers: "of the rules that match, which one applies?"

• Inheritance:

  • When no declaration sets a property, an inherited property takes the parent's computed value; non-inherited ones use their initial value.

  • Answers: "if nothing styles this property, where does the value come from?"

• Commonly inherited properties:

  • Mostly text/typography: color, font-*, line-height, text-align, visibility, list-style.

  • Not inherited: box-model and layout props like margin, padding, border, width, display.

• Control keywords: Force inheritance with inherit, reset with initial, or use unset (inherits if the property is inheritable, else initial).

Specificity is a three-part weight (IDs, classes/attributes/pseudo-classes, elements/pseudo-elements) compared left to right; the higher weight wins. But inline styles sit above all selector-based rules, so in your example the inline style wins over the ID + two classes selector.

• The (a, b, c) model:

  • a = number of IDs, b = classes/attributes/pseudo-classes, c = type selectors/pseudo-elements.

  • Compared column by column from left; a single ID beats any number of classes.

• The example:

  • ID + two classes selector = (1, 2, 0).

  • Inline style is not part of the (a,b,c) selector scale; it ranks above it (sometimes modeled as a leading 1, e.g. (1,0,0,0)).

  • So the inline style wins.

• Above even inline: Only an !important declaration could override the inline style (unless the inline style is itself !important).

Use !important sparingly: legitimately for utility classes, user/accessibility overrides, or overriding inline styles or third-party CSS you can't edit. Its long-term cost is that it breaks the normal cascade, making styles hard to override and debug.

• Justifiable uses:

  • Forcing a single-purpose utility (e.g. .hidden { display: none !important; }) to always win.

  • Overriding inline styles you can't remove, or vendor/widget CSS outside your control.

  • User stylesheets for accessibility, where it deliberately beats author styles.

• Long-term tradeoffs:

  • It escalates: to override one !important you need another, creating an arms race.

  • It hides the real specificity problem instead of fixing it.

  • Debugging gets harder because the winning rule no longer follows intuitive cascade order.

• Better alternatives: Use Cascade Layers (@layer) to control priority without specificity hacks, or simply write a more specific/well-ordered selector.

The cascade is the algorithm the browser uses to pick a winning declaration when several apply to the same element and property. It weighs origin and importance first, then cascade layers, then specificity, and finally source order.

• Order of priority (highest decided first):

  1. Origin and importance: e.g. user-agent < user < author for normal rules, but the order flips for !important declarations.

  2. Cascade layers: within the same origin, later-declared layers beat earlier ones (reversed for !important).

  3. Specificity: among same-layer rules, the higher (a,b,c) weight wins; inline styles rank above selectors.

  4. Source order: if everything else ties, the last declaration in the source wins.

• Key nuances:

  • Importance is evaluated before specificity, so a low-specificity !important beats a high-specificity normal rule.

  • The cascade only resolves conflicts; if no rule sets a property, inheritance or initial values take over.

Margin collapsing is when adjacent vertical margins combine into a single margin equal to the larger of the two, rather than adding together. It only happens to vertical (top/bottom) margins in normal block flow, never horizontal ones.

• When it occurs:

  • Adjacent siblings: the bottom margin of one block and the top margin of the next collapse.

  • Parent and first/last child: a child's top margin can escape through a parent with no border, padding, or content separating them.

  • Empty blocks: a box's own top and bottom margins can collapse together.

• The result is the largest margin: Two 30px margins collapse to 30px, not 60px.

• How to prevent it:

  • Add padding or border between the margins.

  • Establish a Block Formatting Context on the container (e.g. display: flow-root or overflow: hidden).

  • Use Flexbox or Grid layout, where margins between items don't collapse; or use gap.

Note: collapsing does not happen for floated, absolutely positioned, or flex/grid items.

They produce the same result only sometimes: width: auto lets the box size itself based on its context (and subtracts margins/padding), while width: 100% forces the content box to exactly the parent's available width, ignoring its own margins.

• width: auto (the default for block elements):

  • The browser computes width so margin + border + padding + content fills the containing block.

  • Adding horizontal margins shrinks the content area instead of causing overflow.

• width: 100%:

  • Sets the content box to 100% of the parent's width.

  • With box-sizing: content-box, any margin/border/padding is added on top, so the element overflows the parent.

  • Use box-sizing: border-box to fold padding/border in, but margins still cause overflow.

• Rule of thumb: prefer width: auto for fluid block layouts; reach for 100% only when you truly need to fill the parent and have controlled the box model.

float takes an element out of normal flow and shifts it left or right so inline content (originally text) wraps around it; clearfix is a hack that forces a parent to grow tall enough to contain its floated children.

• Original purpose: Wrapping text around an image or pull-quote, like print magazine layouts.

• How it was (mis)used: Before Flexbox/Grid, developers floated columns to build whole page layouts.

• The collapsing problem: A floated child is removed from flow, so its parent computes a height of zero (collapses), breaking backgrounds and borders.

• The clearfix fix:

  • Add a pseudo-element that clears the floats, forcing the parent to enclose them.

  • Modern alternative: display: flow-root on the parent creates a clean block formatting context with no extra markup.

:has() is a relational pseudo-class that matches an element if it contains (or relates to) elements matching the selector inside it. It's called the "parent selector" because it lets you style an element based on its children, which CSS could never do before.

• How it reads: a:has(b) selects a when it has a descendant b; the styled element is a, not b.

• Beyond parents: Combined with combinators it expresses prior-sibling and conditional relationships, e.g. label:has(+ input:required).

• Architectural impact:

  • Removes the need for JavaScript to toggle classes for many state-driven layouts (e.g. a card with/without an image).

  • Enables truly conditional styling and reduces extra wrapper markup.

• Caveat: It is unforgiving in specificity (takes the most specific argument) and can be expensive, so keep selectors scoped.

:focus matches any element that has focus regardless of how it was reached, while :focus-visible matches only when the browser's heuristics decide a visible focus indicator is helpful (typically keyboard navigation, not mouse clicks).

• :focus:

  • Triggers on click, tap, and keyboard alike.

  • Showing a ring on every mouse click felt noisy, which led many developers to remove outlines entirely (an accessibility regression).

• :focus-visible:

  • Shows the focus ring for keyboard/assistive-tech users but hides it for pointer users.

  • Lets you keep a strong, accessible indicator without the visual noise on mouse clicks.

• Why it matters for UX/a11y:

  • Keyboard users need a clear indication of where they are; never blanket-remove focus styles.

  • Common pattern: reset the default outline only when not focus-visible.

Use :has() when the state you want to style is already expressible in the DOM, because it lets CSS react to a parent based on its descendants without any JavaScript, event listeners, or class toggling.

• It's a true parent/relational selector: Style an element conditioned on what it contains: .card:has(img) or a form row that :has(input:invalid).

• Advantages over JS:

  • Zero JS overhead, no listeners to wire up or clean up.

  • Stays in sync automatically: no risk of class state drifting from actual DOM state.

  • Declarative and resilient: works even if JS fails to load or is disabled.

• When JS is still better:

  • State that isn't in the DOM (fetched data, time-based logic, persisted preferences).

  • Heavy use on huge DOMs can add style-recalc cost, so don't over-apply it.

Attribute selectors match elements based on the presence or value of an HTML attribute, using square brackets, and the substring operators let you match the start, end, or any part of a value.

• Basic forms:

  • [attr]: element has the attribute at all.

  • [attr="value"]: value matches exactly.

  • [attr~="value"]: value is one word in a space-separated list.

  • [attr|="value"]: exact match or value followed by a hyphen (useful for language codes).

• Substring operators:

  • ^=: value starts with the substring (e.g. [href^="https"]).

  • $=: value ends with the substring (e.g. [href$=".pdf"]).

  • *=: value contains the substring anywhere (e.g. [class*="col-"]).

• Case sensitivity: Append i before the closing bracket for case-insensitive matching: [type="email" i].

These are CSS math comparison functions: min() returns the smallest of its arguments, max() the largest, and clamp(min, preferred, max) gives a fluid value bounded by a floor and ceiling.

• min(a, b): Picks the smaller value: acts like a maximum cap (width: min(90%, 600px) never exceeds 600px).

• max(a, b): Picks the larger value: acts like a minimum floor (width: max(50%, 300px) never drops below 300px).

• clamp(min, preferred, max): Scales with the preferred value (often viewport-based) but clamps between min and max; equivalent to max(min, min(preferred, max)).

• Why clamp() beats a media query here:

  • Fluid typography: font-size: clamp(1rem, 2.5vw, 2rem) scales smoothly across every screen width.

  • A media query jumps the size at fixed breakpoints; clamp() interpolates continuously with one declaration and no breakpoint maintenance.

Viewport units (vw/vh) are relative to the browser viewport size, whereas percentages are relative to the element's parent (containing block): this difference shows up most around scrollbars and nesting.

• What they reference:

  • 1vw = 1% of viewport width, 1vh = 1% of viewport height, regardless of any parent.

  • width: 50% = half the parent's content width, so it inherits parent constraints and padding context.

• The scrollbar gotcha:

  • 100vw includes the area under a vertical scrollbar, so it can be wider than the visible content and cause horizontal overflow.

  • width: 100% respects the available content width and avoids that overflow.

• Nesting/containment: Percentages cascade with the parent chain; viewport units ignore parents entirely (handy for full-bleed sections, risky inside constrained layouts).

• Newer units: svh, lvh, dvh address mobile dynamic toolbars that made 100vh unreliable.

A unitless line-height is recommended because it's interpreted as a multiplier of each element's own font size, so child elements compute their spacing from their own text rather than inheriting a fixed pre-computed value.

• How inheritance differs:

  • Unitless: children inherit the factor (e.g. 1.5) and multiply by their own font size.

  • With units (em, px, or even a percentage): the value is computed once on the parent and that fixed length is inherited.

• Why the fixed value causes bugs: If a parent sets line-height: 1.5em and a child has a larger font, the child inherits the parent's small computed height, so lines overlap.

• Takeaway: Set line-height: 1.5 (unitless) on the body so every element scales its line spacing correctly.

All three are gradient image functions, but they differ in how colors progress: linear-gradient along a straight line, radial-gradient outward from a center point, and conic-gradient rotated around a center point.

• linear-gradient:

  • Colors transition along a line at a given angle or direction: linear-gradient(to right, red, blue).

  • Best for backgrounds, fades, and overlays.

• radial-gradient:

  • Colors radiate from a center outward in a circle or ellipse: radial-gradient(circle, red, blue).

  • Good for spotlights, glows, and rounded highlights.

• conic-gradient:

  • Colors sweep around the center by angle, like a clock: conic-gradient(red, blue, red).

  • Ideal for pie charts, color wheels, and progress rings.

• All accept color stops and repeating- variants, and produce images usable anywhere an image is valid.

object-fit controls how a replaced element's content (like an <img> or <video>) is resized to fill its own box; background-size does the conceptually similar thing but for a CSS background-image.

• object-fit values:

  • fill (default, stretches), contain, cover, none, scale-down.

  • Pairs with object-position to control alignment within the box.

• Key differences:

  • Target: object-fit affects real DOM elements (semantic, accessible images); background-size affects decorative CSS backgrounds.

  • An <img> with object-fit still occupies its element box and prints/loads as content; a background may not print and isn't part of the document content.

• Rule of thumb: use object-fit for meaningful media, background-size for purely decorative imagery.

aspect-ratio lets an element maintain a width-to-height proportion (e.g. aspect-ratio: 16 / 9) so its height is derived from its width automatically, replacing the fragile padding-top percentage trick.

• The old hack and its problems:

  • You set height: 0 and padding-top: 56.25% (because percentage padding resolves against width).

  • Needed an absolutely positioned inner child, was unintuitive, and broke when you wanted real content flow.

• What aspect-ratio gives you:

  • One declarative line: the box sizes itself, no wrapper or absolute positioning.

  • Reserves space before media loads, preventing layout shift (good for CLS).

  • If content forces more height, the ratio is overridden unless you constrain it; set min-height carefully.

position: sticky is a hybrid: an element behaves like relative until it hits a defined threshold during scroll, then "sticks" in place like fixed, but only within its scrolling ancestor.

• How it behaves:

  • Starts in normal flow (like relative) and stays there until the offset (e.g. top: 0) is reached on scroll.

  • Then it pins relative to the viewport while its parent stays in view, releasing once the parent scrolls out.

• Versus fixed: fixed is pinned to the viewport permanently and removed from flow; sticky is bounded by its parent and keeps its space in flow.

• Versus absolute: absolute is removed from flow and positioned against its nearest positioned ancestor; sticky never leaves flow.

• Scrolling container requirement:

  • You must set at least one offset (top, bottom, etc.) or it does nothing.

  • It sticks within its nearest scrollable ancestor; an ancestor with overflow: hidden/auto/scroll silently breaks stickiness.

A huge z-index fails when it only competes within its own stacking context: if the element's parent forms a low-priority stacking context, no internal value can lift it above siblings of that parent.

• z-index needs positioning: It only applies to positioned elements (relative, absolute, fixed, sticky) or flex/grid items; on a static element it's ignored.

• Stacking contexts are the real cause:

  • z-index is compared only among siblings inside the same stacking context.

  • If a parent has z-index: 1, a child's 9999 still can't beat an uncle element with z-index: 2.

• Sneaky context creators: opacity < 1, transform, filter, will-change, and mix-blend-mode all create a new stacking context, trapping descendants.

• Fix: compare contexts, not numbers: Raise the z-index of the ancestor that forms the context, or move the element out of it (e.g. portal a modal to <body>).

Media queries respond to the viewport (or device) dimensions, while container queries respond to the size of a component's parent container, letting a component adapt to the space it's given rather than the whole screen.

• Media queries:

  • Trigger on global conditions: @media (min-width: 768px), orientation, prefers-color-scheme, etc.

  • A component's layout is coupled to where the viewport sits, not where the component is placed.

• Container queries:

  • Parent declares container-type: inline-size; children use @container (min-width: 400px).

  • The same card renders differently in a wide main column versus a narrow sidebar, automatically.

• Why it's a strategy shift:

  • Moves responsiveness from page-level breakpoints to truly reusable, context-aware components.

  • Supports design systems: a component is portable and responsive anywhere it's dropped, without knowing the page layout.

Physical properties reference fixed screen directions (top, left, margin-right), while logical properties reference flow-relative directions (block and inline) that adapt automatically to the writing mode and text direction.

• Two axes instead of four sides:

  • Inline axis follows text flow; block axis is the direction lines stack.

  • Examples: margin-inline-start, padding-block-end, inset-inline-start.

• Why they matter for i18n:

  • In RTL languages (Arabic, Hebrew), margin-inline-start flips to the right side automatically; margin-left would stay wrong.

  • In vertical writing modes (Japanese), the block axis runs horizontally, and logical properties follow correctly.

  • One stylesheet works across directions, removing the need for separate RTL overrides.

• Practical takeaway: Prefer logical properties for layout/spacing so localization "just works"; use physical ones only when a direction must be truly fixed.

On mobile, vw and vh are sized against the largest possible viewport, ignoring the browser's dynamic toolbars. So 100vh is often taller than the visible area, causing content to be cut off behind the address bar.

• They are fixed to the large viewport: The spec ties vh to the viewport as if toolbars are retracted, so the value doesn't change as toolbars show/hide.

• The classic bug: A 100vh hero overflows when the address bar is visible; a bottom button can sit hidden under the toolbar.

• No reflow on toolbar toggle: This avoids constant relayout while scrolling, but the trade-off is the visual mismatch.

• Fix: prefer the dynamic units (dvh, svh, lvh) for layout that must match the visible area.

Dynamic viewport units express height relative to the viewport in three states: svh (small, toolbars shown), lvh (large, toolbars hidden), and dvh (dynamic, updates as toolbars appear/disappear). They solve the 100vh overflow problem on mobile browsers with collapsing UI.

• svh = small viewport height: The smallest possible viewport (toolbars expanded); guarantees content always fits.

• lvh = large viewport height: The largest viewport (toolbars retracted); equivalent to the old vh behavior.

• dvh = dynamic viewport height: Tracks the visible viewport live as toolbars toggle, so the element always matches what the user sees.

• The problem solved:

  • Replaces the broken 100vh full-screen layouts that overflowed or hid content behind mobile toolbars.

  • Caveat: dvh can cause layout shift / jank as it recalculates while scrolling; svh is steadier for critical UI.

prefers-color-scheme is a media feature that reports the user's OS/browser theme preference (light or dark). You use it to serve a dark palette automatically without any JavaScript.

• It reads a system setting: Values are light and dark; the browser exposes whatever the user picked in their OS.

• Pair it with custom properties: Define color variables, then override them inside the dark query so the whole theme switches from one place.

• Combine with a manual toggle: Use the media query as the default and let a data-theme attribute override it when the user explicitly chooses.

Animating transform: translate() is far cheaper than animating top/left because transforms are handled by the compositor (often on the GPU) and skip layout and paint, while top/left trigger reflow on every frame.

• top/left hit the full pipeline: Changing them forces layout (geometry recalculation), then paint, then composite, every frame: expensive and jank-prone.

• transform runs on the compositor: It only moves an already-painted layer, skipping layout and paint, so it stays smooth at 60fps.

• opacity behaves the same way: transform and opacity are the two cheap-to-animate properties for this reason.

• Hint the browser: will-change: transform can promote the element to its own layer ahead of time, but don't overuse it (memory cost).

Both deal with varying browser support, but from opposite directions: Progressive Enhancement starts with a working baseline and adds modern CSS on top for capable browsers, while Graceful Degradation builds the full modern experience first and ensures it still works acceptably when features are missing.

• Progressive Enhancement (bottom-up):

  • Baseline works everywhere; enhancements are gated behind feature checks like @supports.

  • Old browsers simply never see the new code, so they're never broken.

• Graceful Degradation (top-down):

  • Build with the latest features, then add fallbacks so older browsers still get a usable (if reduced) result.

  • Relies on CSS's fault tolerance: an unrecognized property is ignored and the previous declaration wins.

• In practice they overlap: A fallback declaration followed by @supports is both at once; PE is generally the safer default mindset.

prefers-reduced-motion is a media feature that detects when a user has asked their OS to minimize animation. You use it to disable or tone down motion for people who experience dizziness, nausea, or distraction from movement (an accessibility requirement).

• It reflects an OS accessibility setting: The value reduce means the user wants less motion; no-preference is the default.

• Why it matters: Large parallax, zooming, and spinning effects can trigger vestibular disorders; respecting this is part of WCAG.

• How to apply it: Wrap motion in @media (prefers-reduced-motion: reduce) and shorten/remove transitions and animations, keeping opacity fades if needed.

Progressive enhancement means building a baseline experience that works everywhere, then layering on modern features for browsers that support them. @supports (the feature query) lets you detect support for a CSS property/value and apply enhanced styles only when it's available.

• Start with a solid baseline: Write CSS that works in older browsers first, so content is usable even if nothing enhances it.

• Feature-detect with @supports:

  • Wraps rules in a query that tests an actual declaration, e.g. @supports (display: grid).

  • Supports and, or, and not to combine or negate conditions.

• Enhance, don't gatekeep: The baseline still renders; @supports only adds polish for capable browsers.

• Contrast with graceful degradation: Progressive enhancement builds up from a working core; graceful degradation builds the full thing then patches fallbacks.

transform-origin sets the pivot point around which transforms are applied. It defaults to the element's center (50% 50%), and changing it shifts where rotations spin and where scaling expands from.

• Syntax: Takes one to three values for x, y, and optional z, using keywords (top, left), percentages, or lengths.

• Effect on rotation: The element rotates around the origin point: a top left origin swings the element like a hinged corner instead of spinning in place.

• Effect on scaling: Scaling grows/shrinks away from the origin: a left-edge origin makes scale() expand rightward while the left edge stays fixed.

• 3D note: The optional z value moves the pivot along the depth axis, affecting rotateX/rotateY pivots.

The timing function controls how a transition's progress maps over time (its acceleration curve), not its duration. linear moves at constant speed, ease and its variants add natural acceleration/deceleration, and cubic-bezier() lets you define a fully custom curve.

• linear: Constant speed start to finish; can feel mechanical.

• ease (the default):

  • Starts slow, speeds up, then slows down; feels natural for most UI.

  • Relatives: ease-in (slow start), ease-out (slow end), ease-in-out (both).

• cubic-bezier(x1, y1, x2, y2):

  • Defines the curve with two control points; all keywords are just presets of this.

  • Y values outside 0–1 create overshoot/bounce effects.

• steps(): A separate stepped function for discrete jumps (e.g. sprite animations), not a smooth curve.

Use Flexbox for laying out content along a single axis (a row or a column), and use Grid when you need to control both rows and columns together. Flexbox is content-driven and one-dimensional; Grid is layout-driven and two-dimensional.

• Flexbox = 1D:

  • Distributes items along the main axis; sizing flows from content (flex-grow/flex-shrink).

  • Best for navbars, toolbars, button rows, centering a single element.

• Grid = 2D:

  • You define rows and columns up front; items align in both directions simultaneously.

  • Best for page layouts, card grids, anything where row and column alignment must match.

• Content-out vs layout-in: Flexbox lets content dictate sizing; Grid lets the defined tracks dictate placement.

• They combine: Common pattern: Grid for the overall page structure, Flexbox inside individual cells.

@font-face is the rule that defines a custom font by pointing to font files, so you can use webfonts beyond system-installed ones. FOUT and FOIT describe two different rendering behaviors while that font loads, and font-display lets you choose which one happens.

• @font-face declares the font: You give it a font-family name, src URLs (often multiple formats), plus font-weight/font-style so the browser maps it correctly.

• FOIT (Flash of Invisible Text): Text is hidden while the webfont downloads, so the user sees blank space until it arrives (bad for perceived speed).

• FOUT (Flash of Unstyled Text): A fallback font renders immediately, then swaps to the webfont once loaded, causing a visible reflow/flicker.

• font-display controls the tradeoff:

  • swap: fallback shown immediately, swap when ready (forces FOUT, prioritizes content visibility).

  • block: short invisible period then fallback (FOIT-like).

  • fallback and optional: very short block, and optional may skip the swap entirely on slow connections.

Vendor prefixes (like -webkit-, -moz-, -ms-) are browser-specific versions of a property used to ship experimental or non-standardized features. Today you should rarely write them by hand: let tooling add them based on your browser targets.

• Why they existed: They let browsers expose features still in flux without locking in a final syntax, so authors could opt in early.

• The problems they caused: Sites hardcoded -webkit- only, so other engines were forced to alias it (the standard largely abandoned the prefix model).

• How to handle them now:

  • Write standard properties and let Autoprefixer (driven by a browserslist config) add only the prefixes your targets need.

  • Check support data (caniuse) before relying on a feature; many modern properties need no prefix at all.

These three are the parts of the flex shorthand that decide a flex item's size: flex-basis is the starting size, flex-grow controls how leftover free space is distributed, and flex-shrink controls how overflow is absorbed.

• flex-basis: the initial main-size: The hypothetical size before grow/shrink apply (default auto, which uses the item's content/width).

• flex-grow: expansion factor: A unitless ratio. If there's free space, items grow proportionally to their grow values; 0 means don't grow.

• flex-shrink: shrink factor: If items overflow, they shrink proportionally (weighted by basis); 0 prevents shrinking. Default is 1.

• Shorthand order: flex: <grow> <shrink> <basis>; e.g. flex: 1 1 0 gives equal flexible columns.

The difference is what the item's starting size is measured from: flex-basis: 0 ignores content and starts at zero, so grow factors split the whole container proportionally; flex-basis: auto starts from the item's content/width, so distribution accounts for existing content size.

• flex-basis: 0 (often written flex: 1): All space is treated as free space and divided purely by flex-grow ratios, giving truly equal/proportional columns regardless of content.

• flex-basis: auto (e.g. flex: 1 1 auto): Each item first reserves its content size, then only the leftover space is distributed by grow, so larger-content items end up wider.

• Practical takeaway: Use 0 for equal-width layouts; use auto when items should keep their intrinsic size and just absorb extra space.

The fr unit represents a fraction of the leftover free space in a grid container after fixed-size items and gaps are accounted for, whereas a percentage is always a share of the container's total size regardless of other tracks.

• fr distributes leftover space:

  • Fixed tracks (px, content, gaps) are subtracted first, then the remaining space is split by fr ratios.

  • e.g. grid-template-columns: 200px 1fr 1fr gives 200px to the first column and splits the rest equally.

• Percentages ignore other tracks and gaps:

  • 50% 50% plus a gap can overflow because the gap is added on top of 100%.

  • fr accounts for gaps automatically, avoiding overflow.

• fr interacts with content: An fr track won't shrink below its content's min-size unless you set minmax(0, 1fr).

• Rule of thumb: use fr for flexible space-sharing; reach for percentages only when you need a size relative to the whole container.

The explicit grid is the set of rows and columns you define yourself; the implicit grid is the extra tracks the browser generates automatically when items are placed outside (or overflow) that defined structure.

• Explicit grid: Created by grid-template-columns, grid-template-rows, and grid-template-areas.

• Implicit grid:

  • Auto-generated when there are more items than defined cells, or an item is placed beyond the explicit lines.

  • Sized by grid-auto-rows and grid-auto-columns (default is auto).

  • grid-auto-flow controls whether new items spill into new rows or columns.

• Why it matters: Dynamic content (lists, feeds) often falls into implicit tracks, so set grid-auto-rows to keep them sized predictably instead of collapsing to content height.

Both auto-fill and auto-fit repeat as many tracks as fit the container, but they handle leftover empty tracks differently: auto-fill keeps empty tracks, while auto-fit collapses them so existing items stretch to fill the row.

• auto-fill preserves empty columns: It packs in as many tracks as fit, even ones with no items, leaving visible gaps at the end of the row.

• auto-fit collapses empty columns: Empty tracks shrink to 0, so the present items expand to take the full width.

• The difference only shows with minmax() and few items: If items fully fill the row, the two behave identically.

CSS multi-column layout flows a single continuous block of content into multiple newspaper-style columns, automatically balancing the content across them. Use it specifically when you have one long stream of text that should wrap from column to column, which neither Flexbox nor Grid does naturally.

• Core properties:

  • column-count sets a fixed number of columns; column-width sets an ideal width and lets the count be responsive.

  • column-gap and column-rule style the spacing and divider lines.

  • break-inside: avoid prevents an element from splitting across a column break.

• When to choose it: Continuous text content (articles, definitions, tag clouds) that should reflow across columns.

• When NOT to use it:

  • Distinct UI components or card layouts: Grid/Flexbox give you 2D control over rows and item placement that multi-column can't.

  • Content flows top-to-bottom then to the next column, so reading order can feel awkward for non-prose.

Reflow (layout) recalculates the geometry and position of elements, while repaint redraws pixels (colors, shadows) without changing layout. Reflow is more expensive because it can cascade through the whole document and always forces a subsequent repaint.

• Reflow / layout:

  • Triggered by geometry changes: width, height, top, margin, font-size, or adding/removing DOM nodes.

  • Reading layout properties like offsetWidth mid-script forces a synchronous reflow (layout thrashing).

• Repaint: Triggered by visual-only changes: color, background, visibility, box-shadow.

• Compositor-only (cheapest): transform and opacity can be handled by the GPU on their own layer, skipping layout and paint.

• Why it matters: Animate with transform/opacity instead of top/width to stay at 60fps; batch DOM reads and writes to avoid forced reflows.

A reflow (layout) is triggered by any change that alters an element's geometry: size, position, or anything that forces the browser to recompute the layout tree. Properties that only change appearance trigger paint or composite instead, which is cheaper.

• Box dimensions: width, height, padding, margin, border.

• Positioning: top, left, right, bottom, position, display, float.

• Content & text: font-size, font-family, line-height, text-align, or changing the actual text/children.

• Forced synchronous reflow (layout thrashing): Reading geometry like offsetHeight, getBoundingClientRect(), or scrollTop right after a write forces the browser to reflow immediately.

• Prefer transform and opacity for animation: they avoid reflow (composite-only).

CSS Custom Properties are variables defined with --name and read with var() that live in the DOM and cascade like any other property. Unlike preprocessor variables (Sass/Less), which are resolved once at compile time and disappear, custom properties exist at runtime and can be read, changed, and inherited dynamically.

• They are part of the cascade and DOM:

  • They inherit and can be scoped per element/selector, so a child can override a value just for its subtree.

  • Readable/writable from JavaScript via getPropertyValue() and setProperty().

• Runtime updates: Changing one triggers the browser to recompute dependent values live (great for theming, dark mode, dynamic state).

• Preprocessor variables differ fundamentally: A Sass $var is substituted at build time; the shipped CSS contains only the final value, with no runtime presence or cascade.

BEM (Block, Element, Modifier) is a naming convention that gives classes a predictable, flat structure so styles stay decoupled and reusable. It solves the specificity wars and naming collisions that plague large CSS codebases by making every class self-documenting and low-specificity.

• The three parts:

  • Block: a standalone component (card).

  • Element: a part of a block, joined with __ (card__title).

  • Modifier: a variant/state, joined with -- (card--featured).

• Problems it solves:

  • Keeps specificity flat (single class selectors), avoiding !important and deep nesting battles.

  • Names encode structure, so you know what a class belongs to without reading the markup.

  • Scoping by convention prevents collisions across components.

• Tradeoff: verbose, sometimes ugly class names; relies on team discipline rather than tooling.

Utility-first CSS (popularized by Tailwind) builds UIs by composing many small, single-purpose classes directly in the markup (flex, pt-4, text-center) instead of writing custom semantic classes per component. You style in HTML rather than authoring new CSS rules.

• Benefits:

  • No naming overhead and little context-switching between HTML and CSS files.

  • CSS stops growing as the app grows: utilities are reused, and the final bundle stays small after purging unused classes.

  • Constraint-based design tokens (spacing, color scales) enforce consistency.

• Tradeoffs vs. semantic naming:

  • Markup becomes verbose and harder to read with long class lists.

  • Repeated patterns need componentization (e.g. a framework component or @apply) to stay DRY.

  • Semantic classes describe meaning (.alert) and centralize change; utilities describe appearance and scatter it across markup.

• Practical view: utilities and semantic classes aren't mutually exclusive: many teams use utilities for layout and extract components for repeated patterns.

Using @import inside CSS to pull in other stylesheets hurts performance because imports are discovered and fetched sequentially rather than in parallel, blocking rendering. Build tooling or HTML link tags are almost always better.

• Serialized, blocking requests:

  • The browser must download and parse the parent file before it even discovers an @import, then fetch that file: nested imports chain, adding round-trips.

  • This delays the critical rendering path and increases time to first paint.

• No parallelism: Multiple <link> tags can download concurrently; chained @import statements cannot.

• Better alternatives:

  • Bundle/concatenate files at build time (Sass, PostCSS, webpack), so @import is resolved before shipping and produces one optimized file.

  • Or use multiple <link rel="stylesheet"> tags in HTML for parallel loading.

• Note: build-time @import (in a preprocessor) is fine; the problem is runtime @import in the shipped CSS.