HTML & CSS Fundamentals Interview Questions

Using elements that describe the actual meaning/role of their content (`<nav>`, `<article>`, `<button>`) instead of generic containers styled to look similar (`<div>` for everything) -- semantic elements give screen readers, search engines, and other tooling real structural information that a purely visual approach discards.

A real `<button>` is automatically keyboard-focusable, activatable with Enter/Space, and announced as a button by screen readers -- a `<div>` gets none of this for free and requires manually reimplementing all of that accessible behavior, which is easy to get wrong or forget.

Common mistake: Building an interactive control as a styled <div onClick> instead of a real <button>, losing keyboard operability and screen-reader semantics for free.

Either wrap the input inside the `<label>` element, or give the input an `id` and set the label's `for` attribute to that same `id` -- both let a screen reader announce the label when the input receives focus, and let clicking the label text focus/activate the input.

<label for="email">Email</label>
<input id="email" type="email" />

Heading elements create a real, navigable document outline that screen-reader users can jump through; text that's merely styled to look like a heading (e.g. a bold `<span>`) provides no such structure -- headings should also be used in order (not skipping levels) to keep that outline meaningful.

It provides alternative text describing the image for screen readers (and for when the image fails to load) -- it should concisely describe the image's actual content/purpose, or be left empty (`alt=""`) for purely decorative images so screen readers skip announcing them entirely.

`<article>` marks content that's independently distributable/reusable (a blog post, a comment); `<section>` groups thematically related content, typically with its own heading; `<div>` carries no semantic meaning at all and should be reached for only when no semantic element fits.

A sighted user can visually connect nearby text to a field, but a screen-reader user needs an explicit association (e.g. `aria-describedby` pointing at the error message's id) -- otherwise the error is announced (if at all) with no clear link to which field it belongs to.

It triggers built-in browser validation preventing submission until the field is filled, giving immediate client-side feedback -- it does not replace server-side validation, since a request can always be sent directly (bypassing the browser's form), so the server must independently enforce the same rule.

It triggers the appropriate on-screen keyboard on mobile devices, enables relevant built-in browser validation, and gives assistive technology more accurate information about the expected input -- purely cosmetic `type="text"` for everything loses all of this.

Browsers' error-recovery behavior for malformed HTML is inconsistent across browsers and can silently produce a different DOM tree than intended, causing CSS/JS to target the wrong elements in some browsers but not others -- relying on error recovery trades a visible error for an invisible, hard-to-debug cross-browser inconsistency.

The algorithm the browser uses to resolve conflicting style rules that could apply to the same element -- based on specificity, source order, and origin (e.g. author styles vs. browser defaults vs. `!important`) -- to decide which single value ultimately wins for each property.

Roughly: element/type selectors (e.g. `p`) < class/attribute/pseudo-class selectors (e.g. `.card`, `[type="text"]`, `:hover`) < ID selectors (e.g. `#header`) < inline styles < `!important`. A more specific selector wins regardless of where it appears in the file.

It overrides the normal specificity/cascade resolution, making styles harder to predict and override later -- once one rule uses `!important`, overriding it requires either another `!important` (an escalating pattern) or increasing specificity elsewhere, both of which make the stylesheet harder to reason about over time.

Common mistake: Reaching for !important to 'win' a specificity fight instead of understanding and fixing the actual selector conflict.

Content, padding, border, and margin -- content is the element's actual content area, padding is space inside the border, the border itself, and margin is space outside the border separating the element from its neighbors.

With `content-box`, a set `width`/`height` applies only to the content area, and padding/border are added on top, making the element's rendered size larger than the declared width; with `border-box`, the declared `width`/`height` includes padding and border, so the element's total rendered size matches what you set.

Common mistake: Setting width: 200px with default content-box sizing and being surprised the element renders wider than 200px once padding/border are added.

Vertical margins between adjacent block-level elements (or a parent and its first/last child, under certain conditions) can collapse into a single margin equal to the larger of the two, rather than summing -- a frequently-surprising CSS behavior that doesn't apply to horizontal margins or to flex/grid children.

`block` elements start on a new line and accept width/height/vertical margin; `inline` elements flow within surrounding text and ignore width/height/vertical margin; `inline-block` flows inline like text but does accept width/height/margin like a block.

It applies styles while the pointer is positioned over an element -- touch devices have no persistent pointer 'hovering,' so hover-dependent interactions (like a menu that only opens on hover) can be difficult or impossible to trigger on touchscreens, which is why hover shouldn't be the only way to reveal important content.

A class selector (`.card`) matches elements with that class in their `class` attribute; an attribute selector (`[type="email"]`) matches elements based on the presence or value of any HTML attribute, not just `class` -- useful for styling elements by a semantic attribute without adding an extra class.

When specificity is tied, the cascade falls back to source order -- the rule that appears later in the stylesheet (or in a later-loaded stylesheet) wins, which is why load order of CSS files/rules matters even when specificity alone doesn't resolve a conflict.

Flexbox provides a real one-dimensional layout system with built-in alignment, spacing, and ordering controls -- centering an element vertically, evenly distributing space, or reordering visually without changing HTML source order all used to require fragile hacks, and are now single, purpose-built properties.

The main axis runs in the direction set by `flex-direction` (row by default); the cross axis runs perpendicular to it. `justify-content` aligns items along the main axis; `align-items`/`align-content` align items along the cross axis.

`flex-basis` sets an item's initial main-axis size before extra space is distributed; `flex-grow` controls how much of any extra available space that item should absorb relative to its siblings; `flex-shrink` controls how much it should shrink relative to siblings when there isn't enough space.

Set `display: flex` on the parent, then `justify-content: center` and `align-items: center` -- this handles centering in both directions without needing to know the child's exact dimensions.

.container {
  display: flex;
  justify-content: center;
  align-items: center;
}

By default, flex items all try to fit on a single line, shrinking as needed; `flex-wrap: wrap` allows items to flow onto multiple lines instead of continuing to shrink indefinitely once they run out of room on the current line.

With very few items, `space-between` can leave items pushed to the far edges with an unnaturally large gap in the middle -- for small/variable item counts, `gap` combined with `justify-content: flex-start` or `center` often produces more visually consistent spacing.

`order` changes an item's visual position within the flex container without changing its position in the actual HTML source (and therefore not its position in the DOM/tab order) -- this can create a real accessibility mismatch between visual and keyboard-navigation order if used carelessly.

Common mistake: Reordering items visually with the order property in a way that no longer matches keyboard tab order, confusing keyboard-only users.

`gap` sets consistent spacing between flex items directly on the container, without needing to add and then carefully remove margins on first/last items to avoid extra edge spacing -- a single, simpler declaration than the older margin-based spacing hacks.

Make the page's root container a flex column (`display: flex; flex-direction: column; min-height: 100vh`), then give the main content area `flex: 1` so it grows to fill available space, naturally pushing the footer to the bottom regardless of content height.

When you need to control layout in two dimensions simultaneously (rows AND columns aligned together, like a dashboard or card grid) -- Flexbox is fundamentally one-dimensional, so achieving true two-dimensional alignment with it requires workarounds that Grid handles natively.

Grid is a two-dimensional layout system -- you define both rows and columns explicitly and place items into that grid -- while Flexbox is one-dimensional, laying items out along a single main axis (with wrapping as a secondary, less-precise mechanism).

Three equal-width columns, each taking one fractional unit (`fr`) of the available space -- `fr` distributes remaining space proportionally, similar in spirit to `flex-grow` but for grid tracks.

.grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1rem;
}

`fr` distributes the space remaining *after* any fixed-size tracks and gaps are accounted for; percentages are based on the full container width regardless of fixed tracks -- mixing `fr` with a fixed-width column (e.g. `200px 1fr`) is a common, robust pattern that percentages can't replicate as cleanly.

It lets you name layout regions (e.g. `"header header" "sidebar main" "footer footer"`) directly in the CSS as a visual ASCII-art-like map, then assign each item to a named area -- far easier to read and maintain than tracking numeric grid-line positions for every item.

`repeat(auto-fit, minmax(200px, 1fr))` automatically fits as many columns as will comfortably hold at least 200px each, wrapping to fewer columns on narrower screens -- a fully responsive grid with zero media queries needed for the column count itself.

grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));

`auto-fill` keeps empty tracks reserved (as if invisible extra columns exist) when there aren't enough items to fill a row, which can leave visible gaps; `auto-fit` collapses those empty tracks, letting the actual items stretch to fill the available space instead.

Set `grid-column: span 2` (or explicit line numbers like `grid-column: 1 / 3`) to span columns, and similarly `grid-row` to span rows -- letting individual items occupy more than one cell of the grid.

Yes -- a common pattern is Grid for the page's overall two-dimensional structure (header/sidebar/main/footer) and Flexbox for one-dimensional alignment within individual grid areas (e.g. centering a row of buttons inside the header cell).

It sets spacing between rows and columns (or set separately via `row-gap`/`column-gap`) -- conceptually the same purpose as Flexbox's `gap`, spacing between tracks/items without needing manual margins, though it applies across two dimensions in Grid.

Forgetting that a grid item's own content needs its own explicit `display` (e.g. `display: flex`) to lay out ITS children -- being inside a grid area doesn't automatically make an item's own children participate in flex/grid layout; that's a separate, independent layout context you have to declare.

Writing your base CSS for the smallest/narrowest screen first, then using `min-width` media queries to progressively add complexity/columns for larger screens -- rather than starting from a desktop layout and using `max-width` queries to squeeze it down, which tends to produce more overrides and fights with the cascade.

It applies a block of CSS rules only when a specified condition (like viewport width) is true -- `@media (min-width: 768px) { .sidebar { display: block; } }` only applies that rule at 768px viewport width or wider.

@media (min-width: 768px) {
  .sidebar { display: block; }
}

Without it, mobile browsers render the page at a fixed desktop-width virtual viewport (typically ~980px) and then zoom out to fit the screen, meaning media queries never actually trigger as expected -- this tag tells the browser to use the device's real width, which is a prerequisite for responsive CSS to work at all on mobile.

`px` is an absolute, fixed unit; `%` is relative to a parent's size; `rem` is relative to the root (`<html>`) element's font size. Using `rem` for font sizes lets a user's browser-level font-size preference (accessibility zoom) scale your entire site's text proportionally, which fixed `px` sizes don't respect.

Without it, an image renders at its natural pixel dimensions regardless of its container's width, potentially overflowing a narrow mobile viewport and breaking the layout -- `max-width: 100%` (with `height: auto`) lets the image shrink to fit its container while keeping its aspect ratio.

Common mistake: Embedding a large fixed-dimension image without max-width constraints, causing horizontal overflow on narrow screens.

A fluid layout continuously adapts using relative units and flexible techniques (like `fr`/percentage-based Grid/Flexbox sizing) without hard jumps; a breakpoint-based layout changes distinctly at specific viewport widths (via media queries) -- most real responsive sites combine both, fluid within a breakpoint and distinct layout changes across breakpoints.

Real mobile devices differ in more than just viewport width -- touch-target size requirements, actual device pixel density, and browser chrome behavior all differ from a resized desktop window -- so real-device or accurate device-emulation testing catches issues a simple browser resize won't.

A commonly cited accessibility guideline is roughly 44x44 CSS pixels -- smaller interactive targets become difficult to tap accurately, especially for users with limited dexterity, even if they look fine visually on a desktop mouse-driven layout.

Use a media query to toggle `display` between the two versions based on viewport width (e.g. show the full nav and hide the hamburger button above a breakpoint, and vice versa below it) -- both markup structures typically exist in the DOM, with CSS controlling which is visible at a given width.

Starting from the most space-constrained version forces prioritizing essential content and interactions first, which tends to produce clearer information hierarchy that then benefits from added space on larger screens -- rather than cramming an already-complex desktop design down until it barely fits mobile.