HTML & Semantic Markup
The structure every web page is built on β and the first language every web developer learns
Category: Frontend
Learning Path: What β Why β Learning Modules β Production Example β Interview Prep
Before you start: you need basic computer literacy (opening a text editor, saving a file, opening a file in a browser) and nothing else β no prior programming experience, no prior web development experience, and no math background are required. This is a genuinely reasonable first technology to learn on this platform. See the Prerequisites tab for the full detail and time estimate.
What is HTML?
Think of a web page the way you'd think of a house under construction. HTML is the frame and rooms β the walls, the doorways, the load-bearing structure that says "this is a room, this is a hallway, this is the front door." CSS is the paint, flooring, and furniture arrangement β how it all looks. JavaScript is the wiring and plumbing β what makes things actually do something when you flip a switch or turn a tap. You can live in a house with no paint. You cannot live in a house with no frame. HTML is that frame.
Technically: HTML (HyperText Markup Language) is a markup language, not a programming language β it has no variables, no loops, no logic. It describes the structure and meaning of content using elements, written as tags like Hello (paragraph) or (top-level heading), most of which wrap content in an opening and closing tag: . The browser reads this markup and builds an in-memory tree representation of it called the DOM (Document Object Model) β this is the actual structure browsers render, and the structure CSS styles and JavaScript manipulates. Every web page you've ever seen, no matter how it was built β hand-coded, generated by React, output by a CMS β ends up as HTML delivered to the browser, because HTML is the only structural language browsers actually understand natively.
Why HTML?
Before any styling or interactivity exists, a browser needs to know what a piece of content actually is β is this a heading or a paragraph? A button or a link? A table of data or a decorative box? HTML answers that question, and getting the answer right is not cosmetic β it's the difference between a page that a screen reader can navigate for a blind user, a page Google can correctly index, and a page a browser can render correctly on a phone, a TV, or a printer, versus a page that's just a pile of visually-styled This is exactly why HTML still matters in a world of React, Vue, and component frameworks: those frameworks don't replace HTML, they generate it. A React component ultimately renders down to The skeleton of every page: doctype, head, body, and the elements that give regions meaning Topics covered: The elements that carry real user input and real content, not just layout Forms are how a page collects information from a user β and browsers do meaningful validation work for free ( Topics covered: Making structure actually usable by everyone, plus the newer elements that reduce JavaScript dependency Topics covered: PSR Formula: Answer every question: Problem β Solution β Result. 45-90 seconds max. Q1. What's the difference between HTML, CSS, and JavaScript? A: Problem: interviewers use this as a baseline check that a candidate actually understands the three-layer model, not just that they can write code. Solution: HTML defines structure and meaning (what a piece of content is β a heading, a button, a list); CSS defines presentation (how it looks); JavaScript defines behavior (what happens when a user interacts with it). Result: this separation is why a well-built page still functions with CSS or JavaScript disabled/failed to load β the structure and meaning survive independently, which is a real resilience property, not just a theoretical one. Q2. Why does semantic HTML matter if A: Problem: a Q3. What's the difference between A: Problem: these are easy to conflate for beginners since both can be styled with CSS. Solution: Q4. What does the A: Problem: Q5. Explain the box model and how it relates to HTML/CSS. A: Problem: this is technically a CSS question but interviewers use it to check whether a candidate understands how HTML elements are actually rendered. Solution: every HTML element renders as a box with content, padding, border, and margin, from the inside out. Q6. How do you make a custom-styled clickable element (not a A: Problem: designers often want a Q7. What's the difference between A: Problem: script loading order affects both page performance and whether a script runs before the DOM it depends on exists. Solution: without either attribute, the browser stops parsing HTML to fetch and execute the script immediately, blocking rendering. Q8. Why is using a A: Problem: tables were the standard layout tool before CSS layout matured, and the habit persists in some legacy code and tutorials. Solution: a screen reader announces a Q9. What is the DOM, and how does it relate to the HTML you write? A: Problem: candidates sometimes conflate "the HTML file" with "the DOM," which causes confusion once JavaScript starts mutating the page. Solution: the HTML you write is parsed by the browser into the DOM β an in-memory tree of node objects β which is what's actually rendered and what JavaScript reads/modifies via Q10. How would you debug a form that submits but the server receives no data for one field? A: Problem: a form field can look correct visually but submit no value, and the cause is almost always a small structural mistake, not a JavaScript bug. Solution: check, in order: does the Open any text editor, paste this into a file named Now open DevTools (F12 or right-click β Inspect), find the Elements panel, and notice the tree structure mirrors exactly what you wrote β that tree is the DOM. Try deleting the , β real HTML elements the browser understands. A developer who doesn't understand what those elements mean semantically will write framework code that looks fine visually but is inaccessible, bad for SEO, and fragile in ways that only show up later β a button built out of a styled onClick handler, for instance, is invisible to keyboard users and screen readers in a way a real never would be. Semantic HTML is the foundation every framework sits on top of, not a legacy skill frameworks made obsolete.Learning Modules
Module 01 β Document Structure & Semantic Elements
, , β π’ Beginnerheader, nav, main, article, section, aside, footer β π’ Beginnerh1-h6) and document outline β π‘ Intermediatediv/span vs. semantic elements β when generic wrappers are actually correct β π‘ IntermediateModule 02 β Forms, Media & Tables
required, type="email", pattern) if the right input types and attributes are used, work that has to be reimplemented in JavaScript if they aren't. Tables should hold genuinely tabular data (rows and columns of related values), not be reached for as a layout tool β a habit inherited from the pre-CSS era of the web that actively harms accessibility today. The picture and video/audio elements let a browser choose the right media source for the device and connection, rather than forcing one fixed file on everyone.form, label, input, select, textarea, button β π’ Beginneremail, number, pattern, required) β π‘ Intermediatetable, thead, tbody, th with scope β π‘ Intermediateimg, srcset, picture β π΄ Advancedvideo/audio elements and accessible captions/tracks β π‘ IntermediateModule 03 β Accessibility & Modern HTML APIs
details/summary for disclosure widgets without JavaScript β π‘ Intermediatedialog element for native modals β π΄ AdvancedcustomElements) as a native way to build reusable elements β π΄ AdvancedProduction Example
Interview Prep
Common Interview Questions
div and span can be styled to look identical?div styled to look like a button is visually indistinguishable from a real , but functionally very different. Solution: semantic elements carry built-in meaning that browsers, screen readers, and search engines all consume β a is automatically keyboard-focusable, triggers on Enter/Space, and is announced as "button" by a screen reader; a styled id and class?id must be unique per page (one element only) and is used for direct targeting β anchor links (#section), label for=, or a single specific JavaScript hook. class can apply to many elements and is the right default for reusable styling. Result: using id for styling that applies to multiple elements is a common beginner mistake that makes CSS harder to reuse; the practical rule is "class for style, id for a single unique target."alt attribute on img actually do, and when should it be empty?alt text is often treated as optional or purely an SEO trick, missing its actual purpose. Solution: alt provides the textual equivalent of an image for screen reader users and for cases where the image fails to load β it should describe the image's content or function, not just restate "image of X" redundantly. For a purely decorative image that conveys no information (a background flourish), alt="" (empty, not omitted) is correct β it tells assistive technology to skip it entirely rather than announce a meaningless filename. Result: getting this distinction right is a real, testable accessibility requirement (WCAG), not a nice-to-have.box-sizing: border-box (vs. the default content-box) changes whether padding/border are included inside the element's declared width or added on top of it. Result: this explains a very common bug β an element with width: 100% plus padding that overflows its container unexpectedly, fixed by box-sizing: border-box.) accessible? styled as a button, which breaks keyboard accessibility by default. Solution: the honest answer is "don't β use a real or and style it," since that gets focusability, keyboard activation, and screen-reader semantics for free. If a non-native element is genuinely unavoidable, it needs role="button", tabindex="0", and manually wired keydown handling for Enter/Space. Result: most interviewers are listening for whether the candidate reaches for the real element first rather than jumping straight to the ARIA patch β the patch is real but strictly a fallback, not a first choice. and ?async fetches in parallel but executes as soon as it's ready, potentially before the DOM is fully parsed and out of order relative to other scripts. defer fetches in parallel but executes only after HTML parsing completes, in document order. Result: defer is the right default for scripts that need the DOM and need predictable order (most application scripts); async suits independent scripts like analytics that don't depend on or get depended on by anything else. for page layout considered a real anti-pattern today?
as tabular data β rows, columns, headers β which is actively confusing and wrong when the table is really just a layout grid with no genuine row/column data relationship. It's also rigid and hard to make responsive compared to CSS Grid/Flexbox. Result: the fix is using
exclusively for genuinely tabular data, and CSS Grid or Flexbox for layout β this is a hard rule on this platform's content, not a style preference.
document.querySelector, .appendChild, etc. Changing the DOM with JavaScript doesn't change the original HTML source file at all; "View Source" shows the original file, while DevTools' Elements panel shows the live DOM, and after JavaScript runs, these two can differ significantly. Result: understanding this distinction resolves a very common beginner confusion: "why does my code work but View Source doesn't show my changes."input/select/textarea have a name attribute (submission uses name, not id)? Is it actually inside the element (an input outside the form tag, even if visually nearby, won't submit with it unless linked via the form="" attribute)? Is it disabled (disabled inputs never submit; readonly ones do)? Result: this is a genuinely common real-world bug, and the fix is almost always one of these three structural HTML issues, not a scripting problem β worth checking before reaching for JavaScript debugging tools.Official Resources
Try It (2 Minutes)
try-it.html, and open it directly in a browser (double-click it, no server needed): text directly in DevTools and watch the page update live, with your saved file untouched.

