HTML and CSS Interview Questions and Answers

Semantic HTML means choosing elements by their meaning, not their default look: <nav> for navigation, <button> for actions, <h1> to <h6> for headings, <article> for a self-contained piece of content.

It matters because:

• Accessibility: screen readers announce landmarks, headings and controls, so users can navigate the page.
• SEO: search engines understand the structure and importance of your content.
• Maintainability: other developers can read the structure at a glance.
• Free behaviour: a real <button> is focusable and works with Enter and Space without any JavaScript.

<!-- Non-semantic -->
<div class="header"><div class="nav">...</div></div>
<div class="btn" onclick="buy()">Buy now</div>

<!-- Semantic -->
<header><nav aria-label="Main">...</nav></header>
<button type="button" onclick="buy()">Buy now</button>

Likely follow-up: What does a screen reader announce for a div with an onclick handler?

• <div> has no meaning. Use it purely for styling or layout.
• <section> is a thematic group of content, usually with its own heading, like "Pricing" or "FAQ".
• <article> is self-contained content that would make sense on its own or if shared elsewhere: a blog post, a product card, a comment.

A useful test: if you'd give it a heading, it's probably a <section>; if it could be published on its own, it's an <article>; if it's just a wrapper for CSS, it's a <div>.

<section aria-labelledby="ebooks-title">
  <h2 id="ebooks-title">All ebooks</h2>
  <article class="card">
    <h3>React Interview Questions</h3>
    <p>₹299</p>
  </article>
</section>

Likely follow-up: Can an article contain sections, and a section contain articles?

Every element is drawn as a rectangular box made of four layers, from the inside out:

• content: the text, image or child elements
• padding: space inside the box, between content and border (it shows the background)
• border: the line around the padding
• margin: space outside the border, separating it from other elements (always transparent)

.card {
  width: 300px;
  padding: 16px;
  border: 2px solid #dce1ea;
  margin: 24px;
}

With the default box-sizing: content-box, width sets only the content width, so this card actually takes 300 + 16×2 + 2×2 = 336px of width, plus 24px of margin on each side. Browser DevTools show this as a coloured box diagram, which is the fastest way to debug sizing.

Likely follow-up: How would you make a 300px card stay exactly 300px wide with padding?

box-sizing decides what width and height include:

• content-box (default): width is the content only; padding and border are added on top.
• border-box: width includes padding and border; the content shrinks to fit.

*,
*::before,
*::after {
  box-sizing: border-box;
}

.sidebar {
  width: 25%;
  padding: 20px;
}

With border-box, a 25% sidebar with padding is still exactly 25% wide, which makes layouts far more predictable. That's why almost every modern project starts with the global rule above.

Likely follow-up: Does box-sizing affect margins?

Flexbox lays out children in one direction, a row or a column, and controls how they grow, shrink, align and space out.

• The main axis runs in the flex-direction: horizontal for row (the default), vertical for column.
• The cross axis is perpendicular to it.

.toolbar {
  display: flex;
  flex-direction: row;
  justify-content: space-between;
  align-items: center;
  gap: 12px;
}

Most confusion comes from forgetting that the axes swap when you set flex-direction: column: then justify-content controls vertical placement and align-items controls horizontal.

Likely follow-up: In a column flex container, how do you centre items horizontally?

• justify-content distributes items along the main axis: flex-start, center, flex-end, space-between, space-around, space-evenly.
• align-items aligns items on the cross axis: stretch (the default, so items fill the container's height in a row), flex-start, center, flex-end, baseline.
• align-content spaces out multiple rows of wrapped items on the cross axis (it does nothing for a single line).

.header {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

.price-row {
  display: flex;
  align-items: baseline;
  gap: 8px;
}

align-items: baseline lines up text of different sizes along their text baseline, perfect for a big price next to a small crossed-out MRP.

Likely follow-up: Why are my flex items stretching to the full height of the container?

Responsive design means one website adapts its layout to any screen size, from a 320px phone to a wide desktop, instead of building separate mobile and desktop sites.

It's built on three ideas:

• Fluid layouts: widths in %, fr and max-width instead of fixed pixels
• Flexible media: images and videos that scale (max-width: 100%)
• Media queries (and container queries) to change the layout at certain widths

.container {
  width: 100%;
  max-width: 1200px;
  margin: 0 auto;
  padding: 0 16px;
}

img, video {
  max-width: 100%;
  height: auto;
}

.grid {
  display: grid;
  grid-template-columns: 1fr;
}

@media (min-width: 768px) {
  .grid {
    grid-template-columns: 1fr 1fr;
  }
}

It also needs the viewport meta tag, so phones don't zoom out to a fake desktop width.

Likely follow-up: What is the difference between responsive and adaptive design?

Mobile-first CSS writes the base styles for small screens, then adds min-width media queries to enhance the layout on larger screens. Desktop-first does the opposite with max-width queries.

/* Mobile first: base styles are for phones */
.nav-links { display: none; }
.cards { grid-template-columns: 1fr; }

@media (min-width: 768px) {
  .nav-links { display: flex; }
  .cards { grid-template-columns: repeat(2, 1fr); }
}

@media (min-width: 1200px) {
  .cards { grid-template-columns: repeat(4, 1fr); }
}

Why it's preferred:

• Phones get the simplest CSS without having to undo desktop styles.
• It forces you to prioritise the essential content.
• It matches reality: most users, especially in India, are on mobile.

Likely follow-up: When might desktop-first still make sense?

When several rules target the same element and property, specificity decides which wins. It's counted as three numbers, compared left to right:

• (a) ID selectors: #header
• (b) classes, attribute selectors and pseudo-classes: .card, [type="email"], :hover
• (c) element selectors and pseudo-elements: div, ::before

p                      /* (0, 0, 1) */
.price                 /* (0, 1, 0) */
.card .price           /* (0, 2, 0) */
#ebooks .card .price   /* (1, 2, 0) */
button:hover           /* (0, 1, 1) */

Any number of classes never beats a single ID: (0, 10, 0) loses to (1, 0, 0). Inline style attributes beat all selectors, and !important beats normal declarations. The universal selector * and :where() add zero.

Likely follow-up: What is the specificity of :is(#id, .class) and of :where(#id)?

The cascade resolves conflicts in this order:

1. Origin and importance: browser defaults, then your styles; !important declarations reverse the priority.
2. Cascade layers (@layer): later layers win over earlier ones; unlayered styles win over layered ones.
3. Specificity: the more specific selector wins.
4. Order of appearance: if everything else is equal, the rule that comes last wins.

@layer reset, components, utilities;

@layer components {
  .button { background: #2f4bff; }
}

@layer utilities {
  .bg-dark { background: #18213a; }
}

Here .bg-dark wins over .button even though their specificity is equal, because its layer comes later. Layers are a modern, clean way to organise CSS without specificity wars.

Likely follow-up: Why do unlayered styles beat styles inside @layer?