What HTML is
A markup language, not a program — and why that distinction shapes everything else.
HTML stands for HyperText Markup Language, and the third word is the one that gets ignored. Most people picking it up for the first time treat it like another programming language — something that runs. It doesn't. HTML describes, and the browser does the running.
That distinction shapes everything else: why HTML looks the way it does, why browsers tolerate broken markup that no compiler would accept, and why the same file can render on a Game Boy from 1998 and a 6K display today.
A markup language, not a program
A program is a sequence of instructions — compute this, then loop, then return that. Markup is a sequence of labels — this chunk of text is a heading, that one is a paragraph, this one is a link. There are no variables, no conditionals, no functions. You don't call a <p>; you wrap something in it.
<h1>Hello</h1> <p>Welcome to the page.</p> <a href="/about">About us</a>
Each tag names what its content is: a top-level heading, a paragraph, an anchor pointing somewhere. The browser then decides how to display that — what font size, what color, whether the link is underlined. You can override every default with CSS, but the meaning in the markup stays the same.
This is why screen readers, search-engine crawlers, and reader modes can extract the structure of a page without running any of its scripts: HTML is a contract about what each chunk represents.
<h1>Pricing</h1>. Which statement is most accurate?The browser as a forgiving runtime
If you write a typo in JavaScript, you get a syntax error and nothing runs. If you write busted HTML, the browser shrugs and renders something anyway. Forget to close a tag, mistype an attribute, mix up the order of <head> and <body> — the page still appears.
That's not sloppiness in the spec; it is the spec. The HTML parser has formal rules for recovering from malformed input: missing tags get inserted automatically, stray text gets wrapped in implicit <body>, optional closing tags are inferred. Two browsers parsing the same broken page produce the same broken DOM, which is why the web hasn't fallen apart over thirty years of copy-pasted markup.
Forgiveness has a cost. The browser silently fixing your mistakes means broken markup still works — until the day a screen reader, an SEO crawler, or a future browser interprets it differently. Validate your HTML when something looks off.
The flip side: you can't trust "it renders" as proof your HTML is correct. You need a validator (or your editor's linter) to catch the mistakes the browser is silently papering over.
<p> before opening a new <p>. What happens?HTML, CSS, JavaScript
A modern web page is three languages doing three jobs:
- HTML says what is on the page — headings, paragraphs, lists, forms.
- CSS says how it looks — colors, layout, spacing, typography.
- JavaScript says how it behaves — clicks, fetches, DOM updates.
You can build a usable, accessible page with only HTML. It will be plain and static, but it will work — links will navigate, forms will submit, screen readers will read it. CSS makes it pleasant; JavaScript makes it interactive. The order matters: anything that depends on JS being available needs a fallback, because users on flaky networks or restrictive browsers will see your HTML first, sometimes only.
This separation is why "HTML basics" is a foundation course rather than a footnote. The structure you give a page in HTML is what every other layer attaches to. Get the markup right, and the CSS and JS that ride on top become much easier to write — and stay easier as the page grows.