Advanced HTML Interview Questions and Answers

This is the critical rendering path:

1. The browser parses the HTML into the DOM (Document Object Model) tree.
2. It parses CSS into the CSSOM.
3. It combines them into the render tree (only visible elements, with their computed styles).
4. Layout works out the size and position of every box.
5. Paint fills in pixels, and compositing combines layers on screen.

Classic scripts without defer or async pause DOM parsing, and stylesheets block rendering (and the scripts that follow them), which is why resource loading order matters.

The HTML standard defines exact error-recovery rules, so every modern browser builds the same DOM from the same broken markup. For example, a <p> is closed automatically when a block element such as <ul> starts, missing <html>, <head> and <body> are created, and misnested formatting elements are repaired. The result may not be what the author meant, which is why validation matters.

They are resource hints written as <link rel="...">:

• preload: fetch a resource needed for the current page early, at high priority (as="font", as="image"), such as a hero image or a font discovered late in CSS.
• preconnect: open the connection (DNS, TCP, TLS) to another origin early.
• dns-prefetch: only resolve the domain name early; cheaper than preconnect.
• prefetch: fetch a resource likely to be needed for a future navigation, at low priority.

Overusing them wastes bandwidth and can delay more important resources.

• LCP (Largest Contentful Paint): do not lazy-load the main image; consider fetchpriority="high" or preload for it; serve correctly sized images with srcset; avoid render-blocking scripts.
• CLS (Cumulative Layout Shift): set width and height (or an aspect ratio) on images, videos and iframes, and reserve space for ads and embeds.
• INP (Interaction to Next Paint): keep main-thread JavaScript light, load non-critical scripts with defer or async, and use native elements, which are cheaper than JavaScript-built widgets.

Do not use ARIA when a native HTML element or attribute already provides the semantics and behaviour you need. A <button> is focusable, keyboard-operable and announced correctly; <div role="button"> needs tabindex, key handlers and more to match it. ARIA changes only what assistive technology is told, not behaviour, and incorrect ARIA is worse than none.

Browsers follow the accessible name computation, which roughly takes the first available of: aria-labelledby (text of the referenced elements), aria-label, then native labelling (an associated <label>, alt for images, <caption> for tables, <legend> for fieldsets), then the element's text content for roles that allow it (buttons, links), and finally title or placeholder as a last resort. Visible labels are preferred so that what users see matches what is announced.

<dialog> opened with showModal() renders in the top layer, makes the rest of the page inert, moves focus into the dialog, closes on Esc, provides a ::backdrop, and supports <form method="dialog"> with returnValue. You should still give it a heading or aria-labelledby, choose a sensible element to focus first (the autofocus attribute can help), and make sure focus returns to a sensible place when it closes.

• Cross-site scripting (XSS): inserting untrusted text as HTML lets attackers run scripts. Escape output (<, &), use textContent instead of innerHTML, and add a Content Security Policy.
• Clickjacking: prevent framing with X-Frame-Options or CSP frame-ancestors.
• Third-party content: sandbox iframes, and use Subresource Integrity (integrity attribute) for scripts from CDNs.
• Data exposure: never put secrets in HTML, comments or data-* attributes; validate all form input on the server.

The HTML source is the text the server sent. The DOM is the live object tree the browser built from it, after error correction, and after any changes made by JavaScript. View Page Source shows the original text; the developer tools' Elements panel shows the current DOM. For pages rendered by JavaScript frameworks, the two can be very different.

• The hidden attribute and display: none remove the element from layout and from the accessibility tree.
• visibility: hidden hides it visually but keeps its space in the layout; it is also hidden from assistive technology.
• aria-hidden="true" keeps it visible but hides it from assistive technology (for decorative content).
• A "visually hidden" CSS class (clipping the element to 1 pixel) hides content visually while keeping it available to screen readers, for example for skip links or extra context.

If the HTML is only produced in the browser by JavaScript, the first paint waits for scripts to download and run, content can be missing for crawlers or link-preview bots that do not run JavaScript, and failures leave a blank page. Server-side rendering or static generation sends real HTML first, which improves load time, SEO and resilience; JavaScript then adds interactivity (hydration).

A set of browser standards for reusable, encapsulated custom elements: Custom Elements (customElements.define("my-card", MyCard), names must contain a hyphen), Shadow DOM (a scoped DOM and CSS for the component), and <template>/<slot> (inert markup to clone and placeholders for child content). They work in any framework or none.