DOM APIs & Browser Internals Questions

Understanding DOM traversal methods, manipulation, and performance considerations. Understanding the difference between innerHTML and textContent, element creation methods, fragment optimization. Event handling: event delegation, event bubbling and capturing, event listeners optimization. Knowing when DOM operations cause reflows and repaints. Understanding MutationObserver and other browser APIs.

MediumTechnical

39 practiced

Design a small JavaScript function that safely renders user-provided HTML that may include a limited set of tags (for example <b>, <i>, <a>). You cannot use third-party sanitizer libraries. Describe the whitelist approach, attribute filtering (for href, target, rel), and implement a safe insertion using DOMParser or programmatic element creation. Discuss remaining risks and trade-offs.

Sample Answer

**Brief approach (whitelist + attribute filtering)**

I’d parse the user HTML with DOMParser, walk the resulting nodes, and only recreate allowed tags (<b>, <i>, <a>, <u>, <strong>, <em>, text). For <a> I’ll validate href (only http(s) and mailto), strip javascript: and data: URIs, and enforce safe attributes: target="_blank" must add rel="noopener noreferrer".

**Implementation (vanilla JS)**

javascript

// Sanitize user HTML, returning a DocumentFragment safe to insert
function sanitizeHtml(input) {
  const ALLOWED_TAGS = new Set(['B','I','STRONG','EM','U','A']);
  const parser = new DOMParser();
  const doc = parser.parseFromString(input, 'text/html');
  const frag = document.createDocumentFragment();

  function safeHref(href) {
    try {
      const url = new URL(href, location.href);
      return (url.protocol === 'http:' || url.protocol === 'https:' || url.protocol === 'mailto:') ? url.href : null;
    } catch (e) { return null; }
  }

  function walk(node, target) {
    if (node.nodeType === Node.TEXT_NODE) {
      target.appendChild(document.createTextNode(node.textContent));
      return;
    }
    if (node.nodeType !== Node.ELEMENT_NODE) return;
    const tag = node.tagName;
    if (!ALLOWED_TAGS.has(tag)) {
      // recurse children but skip the element itself
      node.childNodes.forEach(child => walk(child, target));
      return;
    }
    const el = document.createElement(tag.toLowerCase());
    if (tag === 'A') {
      const href = node.getAttribute('href') || '';
      const safe = safeHref(href);
      if (safe) {
        el.setAttribute('href', safe);
        // preserve target only if _blank, but ensure rel is safe
        if (node.getAttribute('target') === '_blank') {
          el.setAttribute('target', '_blank');
          el.setAttribute('rel', 'noopener noreferrer');
        }
      }
    }
    node.childNodes.forEach(child => walk(child, el));
    target.appendChild(el);
  }

  doc.body.childNodes.forEach(n => walk(n, frag));
  return frag;
}

**Why this works**- Whitelist ensures only known-safe tags appear.- href validation blocks javascript: and other dangerous schemes.- Enforcing rel noopener+noreferrer prevents tab-nabbing when opening new windows.

**Remaining risks & trade-offs**- Not a full HTML sanitizer—edge cases include CSS in style attributes or SVG/MathML; we simply drop non-whitelisted elements but don't handle complex attributes (e.g., on* event handlers are removed by only copying allowed attrs).- Parser differences across browsers are minor but acceptable.- For production, prefer well-tested libraries (DOMPurify). This custom approach is fine for small controlled whitelists and low risk inputs.

EasyTechnical

35 practiced

Compare element.innerText and element.textContent. Explain differences in behavior (layout-dependent versus raw text), performance implications when reading or setting each, cross-browser nuances, and examples that show different outputs when elements are hidden or have CSS affecting visibility.

Sample Answer

**Definition & core difference**- element.textContent returns the raw text content of a node and its descendants (no consideration of CSS or layout).- element.innerText returns the “rendered” text as the user sees it — it respects CSS (visibility, display, pseudo-elements in some browsers), and normalizes whitespace like a browser render.

**Behavioral differences**- Layout-dependent vs raw: - textContent ignores CSS, returns all text even from hidden elements (display:none, visibility:hidden). - innerText is layout-aware: hidden via display:none is typically omitted; CSS may affect line breaks/whitespace.- Whitespace: textContent preserves original whitespace; innerText collapses to what the renderer shows.

**Performance**- textContent is faster for reading/setting because it’s a simple DOM tree traversal and doesn’t force reflow.- innerText may trigger layout reflow to compute visible text -> slower, avoid in hot loops.

**Cross-browser nuances**- innerText originated in IE; modern browsers implement it but edge cases differ (e.g., how pseudo-elements or <script>/<style> are treated). Prefer textContent unless you need rendered output.- Use feature detection if relying on innerText differences.

**Examples**Reading hidden element:

const el = document.querySelector('#foo'); // <div id="foo" style="display:none"> A   B </div>
el.textContent   // " A   B "
el.innerText     // ""     (likely empty because display:none)

Whitespace/line breaks:

// <div id="x">A<br>B</div>
x.textContent // "A\nB" or "A B" depending on structure
x.innerText   // "A\nB" (as rendered)

**Recommendation (Frontend)**- Use textContent for manipulation and performance-critical reads/writes.- Use innerText only when you need text exactly as presented to the user.

EasyTechnical

59 practiced

Explain two approaches to determine if an element is visible in the viewport: polling with getBoundingClientRect inside scroll/resize handlers (with throttling/debouncing) and using IntersectionObserver. Compare performance, accuracy, and browser support, then provide example code for lazy-loading an image using both methods.

Sample Answer

**Approach overview**

- Polling with getBoundingClientRect inside scroll/resize handlers - Add event listeners, read element.getBoundingClientRect(), check intersection with viewport. - Must throttle/debounce to avoid layout thrashing and high CPU.

- IntersectionObserver - Browser API that asynchronously notifies when element enters/exits viewport (or threshold). - Offloads work to browser compositor thread; more efficient.

**Performance, accuracy, browser support**

- Performance - getBoundingClientRect: can cause sync layout reads; costly if many elements or frequent events. Throttling reduces frequency but still runs JS on main thread. - IntersectionObserver: optimized, runs off main thread; minimal overhead even with many targets.

- Accuracy - getBoundingClientRect: exact at time of call; must handle transforms, fixed elements, and partial visibility logic yourself. - IntersectionObserver: handles transforms, CSS, and provides intersectionRatio; more robust.

- Browser support - getBoundingClientRect: universal. - IntersectionObserver: supported in modern browsers; polyfill needed for older browsers (IE11, old Safari).

**Examples**

- Polling + throttle lazy-load (vanilla JS)

javascript

// Throttle helper
function throttle(fn, wait=100){
  let last=0;
  return (...args)=>{
    const now = Date.now();
    if(now - last >= wait){ last = now; fn(...args); }
  };
}

function inViewport(el){
  const r = el.getBoundingClientRect();
  return r.top < window.innerHeight && r.bottom > 0 && r.left < window.innerWidth && r.right > 0;
}

const imgs = Array.from(document.querySelectorAll('img[data-src]'));
function checkImages(){
  imgs.forEach(img=>{
    if(inViewport(img)){
      img.src = img.dataset.src;
      img.removeAttribute('data-src');
    }
  });
}

const onScroll = throttle(checkImages, 150);
window.addEventListener('scroll', onScroll);
window.addEventListener('resize', onScroll);
document.addEventListener('DOMContentLoaded', checkImages);

- IntersectionObserver lazy-load

javascript

const imgs = document.querySelectorAll('img[data-src]');
if('IntersectionObserver' in window){
  const io = new IntersectionObserver((entries, observer)=>{
    entries.forEach(entry=>{
      if(entry.isIntersecting){
        const img = entry.target;
        img.src = img.dataset.src;
        img.removeAttribute('data-src');
        observer.unobserve(img);
      }
    });
  }, { root: null, rootMargin: '100px', threshold: 0.1 });

  imgs.forEach(img => io.observe(img));
} else {
  // Fallback to the throttled getBoundingClientRect approach
}

Use IntersectionObserver for best performance and accuracy; fallback to polling for full compatibility.

MediumTechnical

34 practiced

You have code that iterates a list of elements and alternates reading offsetHeight and then setting style.height on each iteration. Explain why this causes layout thrashing and poor performance. Provide a refactored implementation that separates reads from writes to avoid repeated reflows and explain the benefits of your approach.

Sample Answer

**Brief explanation (why it’s bad)**

Reading layout properties (offsetHeight) then immediately writing style.height in a loop forces the browser to flush pending style changes and recompute layout on each iteration. That repeated read -> write -> read pattern is layout thrashing (many synchronous reflows), causing high CPU and jank.

**Refactored approach**

- First pass: collect all required reads (measurements) into an array.- Second pass: apply all writes (style changes) using the cached values.- Optionally wrap writes in requestAnimationFrame to align with paint.

javascript

// Read phase: measure all items
const items = Array.from(document.querySelectorAll('.item'));
const heights = items.map(el => el.offsetHeight);

// Write phase: update styles in one batch
requestAnimationFrame(() => {
  items.forEach((el, i) => {
    el.style.height = heights[i] + 'px';
  });
});

**Benefits**

- Eliminates repeated reflows: browser computes layout once for reads, then once for writes.- Reduces CPU and improves frame rate.- More predictable and easier to optimize (can add throttling/debouncing).

**Edge notes**

- If writes affect subsequent reads elsewhere, ensure isolation or recompute as needed.- For large lists, virtualize instead of batching DOM for further gains.

EasyTechnical

44 practiced

Compare three DOM insertion approaches: document.createElement + appendChild, element.insertAdjacentHTML, and element.innerHTML = '...'. Describe differences in parsing, performance, how scripts in the inserted HTML are handled, and security trade-offs. Provide guidance on when to prefer programmatic creation versus HTML string insertion in interactive UI code.

Sample Answer

**Brief summary**

Three common insertion methods differ in how the browser parses HTML, executes scripts, performs, and exposes security risks. Below I compare them and give practical guidance.

**document.createElement + appendChild**- Parsing/DOM: You build nodes directly; no HTML parser for that fragment.- Performance: Lower overhead for small, interactive components; avoids reparsing parent innerHTML.- Scripts: Scripts must be created and appended explicitly; they don’t execute automatically.- Security: Safer against injection because you control each node and can set textContent to avoid HTML interpretation.- Use when: Creating interactive widgets with event handlers, dynamic attributes, or when reusing refs.

**element.insertAdjacentHTML**- Parsing/DOM: Uses HTML parser to create nodes and inserts at specified position (beforebegin, afterbegin, beforeend, afterend).- Performance: Faster than innerHTML for appending because it avoids replacing the container; good for batch inserts.- Scripts: Inline <script> tags inserted as HTML are parsed but typically not executed; inserted external scripts won’t auto-run. Behavior can vary by browser—don’t rely on script execution.- Security: Accepts raw HTML strings — sanitize when content is untrusted.

**element.innerHTML = '...'**- Parsing/DOM: Replaces container’s contents — full parse of new markup.- Performance: Can be expensive for large or frequent updates because it destroys and recreates children and their state/events.- Scripts: Similar to insertAdjacentHTML—inline scripts generally not executed when set via innerHTML.- Security: Highest risk of XSS if you inject untrusted HTML; always sanitize or avoid.

**Practical guidance**- Prefer programmatic creation (createElement/appendChild) for interactive components that need event listeners, references, or predictable lifecycle — it’s safer and clearer.- Use insertAdjacentHTML for fast, trusted-markup inserts (templates, server-rendered snippets) where you need to append many nodes without wiping the container.- Use innerHTML for simple static replacements when content is fully trusted and performance impact is acceptable.- Always sanitize untrusted HTML, use textContent for user text, and consider templating libraries or DOMPurify for security.

Unlock Full Question Bank

Get access to hundreds of DOM APIs & Browser Internals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.