DOM, HTML & CSS

• DOM manipulation concepts; display:none (removed from render tree) vs visibility:hidden (still occupies space).
• HTML semantics (why <header>/<nav>/<article> matter).
• CSS fundamentals: box model, flexbox, grid, specificity, positioning (static/relative/absolute/fixed/sticky).

02 Knowledge check

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

• ▸ Commonly asked junior concept very common What is the difference between display:none and visibility:hidden?

  display:none removes the element from the render tree entirely: it occupies no space, is not painted, and is skipped by most assistive tech. Toggling it triggers reflow.

  visibility:hidden keeps the element in layout — it still occupies its box and affects siblings — but is not painted (invisible). It is not interactive.

  A third option, opacity:0, is fully painted and still interactive (clickable) and laid out; it just renders transparent.

  Follow-ups they push on

  • Which of the three is keyboard-focusable / clickable?
  • Which triggers reflow when toggled vs only repaint?

  Red flag Saying visibility:hidden removes the element from layout — it still occupies space. Confusing opacity:0 (still clickable) with display:none.

  source: MDN — visibility ↗
• ▸ Commonly asked junior concept very common Explain the CSS box model and the box-sizing property.

  Every element is a box with four areas, from inside out: content, padding, border, margin.

  With the default box-sizing: content-box, the width you set applies to the content only; padding and border are added on top, so the rendered box is wider than width.

  With box-sizing: border-box, width includes content + padding + border, so the element stays the size you set. This is why many resets apply * { box-sizing: border-box; }.

  Follow-ups they push on

  • Why do margins collapse vertically between block elements?
  • Does margin count toward the element's width in either box-sizing mode?

  Red flag Forgetting that margin is always outside the box (never part of width), or not knowing border-box folds padding/border into the declared width.

  source: MDN — The box model ↗
• ▸ Commonly asked mid concept common How does CSS specificity work, and what wins between an ID selector and 10 classes?

  Specificity is scored as a tuple (inline, IDs, classes/attributes/pseudo-classes, elements). Higher tuples win; ties are broken by source order (last wins).

  An ID is (0,1,0,0). Ten classes is (0,0,10,0). The ID still wins because the ID column outranks the class column regardless of count — it is not a base-10 sum where 10 classes overflow into the ID column.

  !important overrides normal specificity; inline styles outrank selectors. Use these sparingly.

  Follow-ups they push on

  • Where do !important and inline styles sit in the cascade?
  • How do :where() and :is() affect specificity?

  Red flag Treating specificity as a single base-10 number so '10 classes beat 1 ID' — columns do not carry over.

  source: MDN — Specificity ↗
• ▸ Commonly asked mid concept common When would you use Flexbox versus CSS Grid?

  Flexbox is for one-dimensional layout — a row or a column — where you distribute space along a single axis (nav bars, toolbars, centering, equal-height items in a row).

  Grid is for two-dimensional layout — rows and columns together — where you place items into a defined grid (page layouts, card galleries, dashboards).

  They compose: a grid cell can itself be a flex container. Reach for Grid when you care about both axes at once; Flexbox when content drives a single axis.

  Follow-ups they push on

  • How do you center an element both horizontally and vertically with each?
  • What does flex: 1 actually mean (flex-grow/shrink/basis)?

  Red flag Calling Grid 'just for grids of images' or Flexbox 'two-dimensional'. The key distinction is 1D vs 2D.

  source: MDN — Relationship of grid layout to other layout methods ↗
• ▸ Commonly asked mid concept common Explain CSS position values: static, relative, absolute, fixed, and sticky.

  static — default; in normal flow, top/left ignored.

  relative — stays in flow but offset from its normal spot; becomes a positioning context for absolute children.

  absolute — removed from flow; positioned relative to the nearest positioned ancestor (else the initial containing block).

  fixed — removed from flow; positioned relative to the viewport, so it stays put on scroll.

  sticky — a hybrid: behaves like relative until it crosses a scroll threshold, then sticks like fixed within its container.

  Follow-ups they push on

  • What makes an ancestor a 'positioned' ancestor for absolute children?
  • Why might position:sticky silently not work (overflow on an ancestor)?

  Red flag Saying absolute is relative to the viewport (that is fixed), or that sticky is independent of its containing block.

  source: MDN — position ↗
• ▸ Commonly asked junior concept common Why does semantic HTML matter? Give examples beyond <div> and <span>.

  Semantic elements describe meaning, not just appearance, which benefits accessibility, SEO, and maintainability.

  Elements like <header>, <nav>, <main>, <article>, <section>, <aside>, <footer> create landmarks that screen readers and the accessibility tree expose, letting users jump between regions. <button>, <a>, <label>, <input> come with built-in keyboard behavior and roles.

  A <div> with a click handler has none of that — you would have to re-add role, tabindex, and key handling manually.

  Follow-ups they push on

  • What do you lose by using <div onClick> instead of <button>?
  • How do landmark elements help screen-reader navigation?

  Red flag Treating semantics as purely cosmetic, or reinventing a button from a div without role/tabindex/keyboard support.

  source: MDN — HTML: A good basis for accessibility ↗
• ▸ Commonly asked mid concept occasional What is the difference between the HTML attribute and the DOM property (e.g. input value)?

  The attribute is what is written in the HTML source; the property is the live value on the DOM object. They are linked at parse time but can diverge.

  For an <input value="hi">: getAttribute("value") returns the original "hi" (the default), while inputEl.value reflects what the user has currently typed. Editing the box changes the property, not the attribute.

  Some attributes are reflected (id, className), others are not symmetric (value, checked). This is why React tracks value as state.

  Follow-ups they push on

  • Why does setAttribute('value', ...) not update what the user sees after they have typed?
  • How does this relate to controlled vs uncontrolled inputs in React?

  Red flag Assuming attribute and property always stay in sync. For value/checked the attribute is just the initial default.

  source: MDN — Attributes ↗
• ▸ Amazon mid coding common How would you efficiently insert 1,000 DOM nodes without causing 1,000 reflows?

  Build the nodes off the live DOM and insert once, so layout is recomputed a single time.

  Use a DocumentFragment:

  const frag = document.createDocumentFragment();
for (const item of items) { const li = document.createElement("li"); li.textContent = item; frag.appendChild(li); }
list.appendChild(frag);

  Appending to the fragment does not touch the rendered tree; the single appendChild(frag) inserts all children in one operation. Avoid innerHTML += in a loop (re-parses everything each time) and avoid appending one-by-one to the live list.

  Follow-ups they push on

  • Why is innerHTML += in a loop both slow and unsafe?
  • When would you use virtualization instead of inserting all 1,000 nodes?

  Red flag Appending each node directly to the live DOM in the loop, or using innerHTML += which re-parses the whole list every iteration.

  source: MDN — DocumentFragment ↗
• ▸ Commonly asked senior concept common What is a stacking context, and why might a higher z-index element still appear behind a lower one?

  z-index only orders elements within the same stacking context. A stacking context is a self-contained layer: once formed, its children are painted as a unit, and their z-index values cannot escape it.

  So if element A (z-index: 9999) lives inside a parent that forms a stacking context with a low z-index, and element B (z-index: 1) is in a *sibling* context with a higher one, B paints on top — A's huge z-index is meaningless across contexts.

  New stacking contexts are created by more than position + z-index: opacity < 1, transform, filter, will-change, isolation: isolate, and being a flex/grid child with a z-index, among others. This is the usual cause of 'my z-index isn't working'.

  What a strong answer covers

  • z-index is only comparable within one stacking context, never across them.

  • Once an ancestor forms a context, a child's z-index is trapped inside it.

  • Contexts are created by position+z-index but also opacity < 1, transform, filter, will-change, isolation: isolate.

  • A z-index:9999 child of a low context loses to a z-index:1 element in a higher-ranked sibling context.

  Quick self-check

  Which of these does NOT, by itself, create a new stacking context?

  • opacity: 0.9
  • transform: translateZ(0)
  • position: static (default)
  • isolation: isolate

  Follow-ups they push on

  • Name three properties besides position that create a stacking context.
  • How does `isolation: isolate` help contain z-index without side effects?

  Red flag Assuming z-index is globally comparable. A larger z-index loses if its element sits in a lower-ranked ancestor stacking context.

  source: MDN — Stacking context ↗
• ▸ Commonly asked mid concept common What does flex: 1 actually mean? Break down flex-grow, flex-shrink, and flex-basis.

  flex is shorthand for three properties:

  - flex-grow — how much a item grows to fill leftover free space, relative to siblings.
  - flex-shrink — how much it shrinks when there isn't enough space.
  - flex-basis — the item's starting size before grow/shrink (its 'ideal' main size).

  flex: 1 expands to flex: 1 1 0% — grow 1, shrink 1, basis 0%. Because basis is 0, items size purely by their grow ratio, so equal flex: 1 items become equal width regardless of content. Contrast flex: auto (1 1 auto), where content size is the starting point, so items differ by content length.

  What a strong answer covers

  • flex: <grow> <shrink> <basis>; flex: 1 = 1 1 0%.

  • flex-grow distributes free space; flex-shrink distributes overflow; flex-basis is the pre-grow size.

  • flex: 1 on siblings gives equal sizes (basis 0); flex: auto (basis auto) sizes from content first.

  • flex-basis takes priority over width for the main-axis starting size.

  Follow-ups they push on

  • What's the difference between flex: 1 and flex: auto?
  • When does flex-shrink: 0 matter (preventing an item from collapsing)?

  Red flag Thinking flex: 1 sets a width directly, or confusing flex: 1 (basis 0, equal sizes) with flex: auto (basis auto, content-driven sizes).

  source: MDN — flex ↗
• ▸ Commonly asked junior coding very common How would you center a div both horizontally and vertically? Give more than one approach.

  Flexbox (most common): on the parent,

  display: flex; align-items: center; justify-content: center;

  Grid (terse): on the parent, display: grid; place-items: center;

  Absolute + transform (no flex/grid): on the child,

  position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%);

  The transform trick offsets by the element's own size (the 50% in translate is relative to the element), so it centers regardless of dimensions. Flexbox/grid are preferred for in-flow content; absolute centering suits overlays where the child is taken out of flow.

  What a strong answer covers

  • Flexbox: align-items: center; justify-content: center; on the container.

  • Grid: place-items: center; — the shortest form.

  • Absolute + translate(-50%, -50%) centers without knowing the element's size.

  • Prefer flex/grid for in-flow content; absolute centering for overlays/modals.

  Follow-ups they push on

  • Why does translate(-50%, -50%) work without knowing the element's dimensions?
  • What changes if the parent has a fixed height vs auto height?

  Red flag Using `margin: auto` for vertical centering on a block (works horizontally, not vertically without flex), or forgetting the parent needs a height for flex centering to be visible.

  source: MDN — Box alignment (centering) ↗
• ▸ Commonly asked mid concept occasional Why and when do vertical margins collapse between block elements?

  Margin collapsing is when adjacent vertical margins combine into a single margin equal to the largest of them, rather than summing. It applies only to block-level boxes in normal flow along the block (vertical) axis — never horizontal margins.

  Three cases: adjacent siblings (the bottom margin of one and top margin of the next collapse); a parent and its first/last child (if no border/padding/content separates them); and an empty block (its own top and bottom margins collapse).

  It does not happen for flex/grid items, floated or absolutely-positioned elements, or when a border, padding, or overflow: auto separates the boxes. This trips people up when a child's margin unexpectedly pushes the parent.

  What a strong answer covers

  • Collapsing takes the max of the two margins, not the sum — vertical only.

  • Happens between siblings, parent/first-or-last child, and within empty blocks.

  • Prevented by a border, padding, overflow other than visible, or a BFC.

  • Does not apply to flex/grid items, floats, or absolutely positioned boxes.

  Follow-ups they push on

  • How does establishing a block formatting context (BFC) stop collapsing?
  • Why does a child's top margin sometimes push the parent down?

  Red flag Expecting margins to add up, or thinking collapsing applies to flex/grid items (it doesn't) or to horizontal margins (it doesn't).

  source: MDN — Mastering margin collapsing ↗
• ▸ Commonly asked mid concept common What is the difference between rem, em, %, vw/vh, and px? When would you reach for each?

  px is an absolute (device-independent) pixel — fixed, predictable, but ignores user font preferences.

  em is relative to the current element's font-size (for most properties), so it compounds when nested. rem is relative to the root <html> font-size — no compounding, which makes it the go-to for scalable, accessible typography and spacing.

  % is relative to the parent's corresponding dimension. vw/vh are 1% of the viewport's width/height, useful for full-screen sections.

  Practical default: rem for type and spacing (respects user zoom/root size), %/fr/vw for fluid layout, px for hairline borders.

  What a strong answer covers

  • px: absolute and fixed; doesn't scale with user font settings.

  • em: relative to the element's own font-size — compounds when nested.

  • rem: relative to the root font-size — no compounding; best for accessible, scalable type.

  • % is relative to the parent; vw/vh are 1% of viewport width/height.

  Follow-ups they push on

  • Why can nested em values produce surprising sizes?
  • Why is rem preferred over px for font sizes from an accessibility standpoint?

  Red flag Confusing em (element-relative, compounds) with rem (root-relative), or using px for font sizes and breaking user zoom/font-size preferences.

  source: MDN — CSS values and units (length) ↗
• ▸ Commonly asked mid concept common What is the difference between event.target and event.currentTarget on a bubbling event?

  event.target is the element where the event originated — the deepest node that was actually clicked/typed-in. event.currentTarget is the element whose listener is currently running — i.e. the element you called addEventListener on.

  During bubbling, target stays constant as the event travels up, while currentTarget changes at each ancestor whose listener fires. In a delegated handler on a <ul>, currentTarget is the <ul>, and target is the specific <li> (or a child of it, which is why you often use target.closest('li')).

  Note: in an arrow function this won't be the element, but event.currentTarget always is.

  What a strong answer covers

  • target = where the event started (deepest element); constant through bubbling.

  • currentTarget = the element whose listener is running now; changes per ancestor.

  • In delegation, currentTarget is the parent you bound to; target is the actual descendant.

  • currentTarget equals this in a normal function handler, but not in an arrow function.

  Quick self-check

  A click listener is on a <ul>. The user clicks a <span> inside an <li>. Inside the handler, what are target and currentTarget?

  • target = the <ul>, currentTarget = the <span>
  • target = the <span>, currentTarget = the <ul>
  • target = the <li>, currentTarget = the <li>
  • Both are the <span>

  Follow-ups they push on

  • Why use target.closest('li') instead of target directly in a delegated handler?
  • What is event.target inside a handler bound directly to the element itself?

  Red flag Swapping the two: target is the origin, currentTarget is the listening element. In delegation, acting on target directly can grab a nested child instead of the row.

  source: MDN — Event: currentTarget ↗
• ▸ Commonly asked mid trick common What is the difference between stopPropagation and preventDefault?

  They are orthogonal. preventDefault() cancels the browser's default action for the event — following a link, submitting a form, checking a checkbox — but the event still propagates to other listeners.

  stopPropagation() stops the event from traveling further through the capture/bubble phases to other elements, but does not cancel the default action. (stopImmediatePropagation() additionally prevents other listeners on the *same* element.)

  So: prevent the default behavior with preventDefault; stop the event reaching parents with stopPropagation. Returning false from a jQuery handler does both, but in plain DOM return false only works in inline on* attributes.

  What a strong answer covers

  • preventDefault() cancels the default browser action; propagation still happens.

  • stopPropagation() halts travel to other elements; default action still happens.

  • stopImmediatePropagation() also blocks other listeners on the same element.

  • They're independent — you sometimes call both, sometimes one.

  Quick self-check

  A form submit handler calls only event.stopPropagation(). What happens?

  • The form does not submit, and parents don't see the event
  • The form still submits; parent listeners just don't receive the event
  • The form submits and parents still receive the event
  • Nothing happens at all

  Follow-ups they push on

  • When would you call both on the same event?
  • Why is calling stopPropagation broadly considered risky for delegation?

  Red flag Believing stopPropagation also cancels the default action (it doesn't), or that preventDefault stops bubbling (it doesn't).

  source: MDN — Event: preventDefault() ↗
• ▸ Commonly asked senior concept occasional What is a block formatting context (BFC), and name two ways to create one. Why is it useful?

  A block formatting context is a self-contained region of layout where block boxes lay out and floats are managed independently of the outside. Inside a BFC, vertical margins don't collapse with elements outside it, and the BFC contains its floated children.

  Ways to create one: overflow other than visible (e.g. overflow: hidden/auto), display: flow-root (the purpose-built, side-effect-free option), being a flex/grid item, display: inline-block, or floating/absolute positioning.

  Classic uses: clearing floats (a floated child no longer overflows its parent's height), and stopping margin collapse between a parent and child. display: flow-root is the modern, intention-revealing way to do both.

  What a strong answer covers

  • A BFC is an isolated layout region; floats and margins inside don't leak out.

  • Create with display: flow-root, overflow ≠ visible, flex/grid item, float, or absolute.

  • Contains floats (no parent collapse) and blocks external margin collapsing.

  • display: flow-root is the clean, side-effect-free way to establish one.

  Follow-ups they push on

  • Why was `overflow: hidden` historically used to clear floats?
  • What advantage does display: flow-root have over the overflow hack?

  Red flag Using `overflow: hidden` to clear floats and accidentally clipping content or scrollbars; `display: flow-root` avoids those side effects.

  source: MDN — Block formatting context ↗