---
title: "02 — HTML — Describing Meaning, Not Painting Pixels"
uid: html-fundamentals
tags: ["seo", "accessibility", "forms", "html", "semantic-html", "roadmap:frontend", "fundamentals"]
excerpt: "HTML describes meaning; how it looks is someone else's job. An
isn't 'big bold text' — it's a claim about what the page's top-level heading is."
date: 2026-08-12T18:12:05+0000
source: https://www.aveshina.my.id/en/blog/html-fundamentals
---
"The tags that make text bold or draw a box" was how I treated HTML, which explained nothing about why the tags exist. The line that everything else hangs off: **HTML describes meaning. How it looks is someone else's job.** [1]
An
doesn't mean "big bold text." It means "this is the top-level heading of the page." Big and bold is just what the browser's built-in stylesheet happens to do with that meaning. Swap the stylesheet (CSS) and the looks change completely; the meaning doesn't budge. I had the relationship backwards for years — I was picking tags for the appearance I wanted, when the only question I needed to answer was *what is this content?*
The payoff of getting that right is that three things I used to think were separate collapse into one. Semantic markup, accessibility, and SEO aren't three skills — they're one activity, "describe the meaning correctly," read by three different machines:
```figure
```
This post you're reading is, at the bottom of the stack from last time, just such a document — the server sends HTML, and the browser turns meaning into the page on your screen. So what's actually in it?
## Elements, attributes, and the tree
HTML is made of **elements** — usually an opening tag, some content, and a closing tag, like