I didn’t fall in love with HTML.
I tolerated it.
Like a lot of developers, I treated HTML as the tutorial zone. The place you pass through on your way to the real game – JavaScript, frameworks, flashy interactions, dragons that breathe async fire. HTML felt like the character sheet you fill out quickly so you can start rolling initiative.
That was a mistake.
Over time – through teaching, debugging, accessibility audits, and rebuilding things I swore I’d never rebuild – I realized something quietly profound:
HTML isn’t just structure. It’s a contract.
A contract between you and the browser.
Between your code and assistive technologies.
Between your present self and future-you at 2:00 a.m. wondering why nothing makes sense anymore.
And like any good tabletop contract, when it’s clear, the campaign sings. When it’s sloppy, chaos reigns.
What I Mean by “Contract”
When I write HTML, I’m not telling the browser how to look.
I’m telling it what things are.
That distinction matters more than we give it credit for.
When I write:
<p>This is a paragraph.</p>I’m making a promise.
I’m saying: “This content is a paragraph of thought. It flows. It belongs in a block. It participates in reading order.”
The browser responds: “Cool. I know what to do with that.”
CSS builds on that promise.
JavaScript enhances it.
Screen readers trust it.
Break the contract, and everything downstream starts rolling with disadvantage.
The Rookie Mistake: Div Everything
I’ve done it. You’ve done it. We’ve all done it.
<div class="title">Welcome</div>
<div class="nav">Home | About | Contact</div>
<div class="content">Stuff goes here</div>It works.
It displays.
It even styles nicely.
But structurally? This is like showing up to a D&D session with a character sheet that says:
Class: Stuff
Skills: Things
Alignment: Probably
The browser has no idea what any of this means.
Now compare that with:
<header>
<h1>Welcome</h1>
</header>
<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
<li><a href="/contact">Contact</a></li>
</ul>
</nav>
<main>
<p>Stuff goes here</p>
</main>Same visual outcome.
Radically different contract.
Now the browser knows:
- What’s navigation
- What’s primary content
- What matters most
- How to help someone move through it without a mouse
This isn’t pedantry. This is system design.
Headings Are Initiative Order
Headings aren’t about font size.
They’re about hierarchy.
When I see this:
<h1>Blog</h1>
<h2>Latest Posts</h2>
<h3>Why HTML Matters</h3>
<h2>Archives</h2>I can feel the structure.
When I see this instead:
<h1>Blog</h1>
<h4>Latest Posts</h4>
<h2>Why HTML Matters</h2>
<h5>Archives</h5>My soul takes psychic damage.
Screen readers rely on headings the way players rely on initiative order. Skip levels, and suddenly the rogue is attacking after the furniture.
The contract says:
- One
<h1>for the main topic - Logical progression downward
- No jumping levels “for style”
Style is CSS’s job. HTML sets the rules of play.
Forms Are Negotiations, Not Decorations
Forms are one of the clearest examples of HTML as a contract.
This looks fine:
<input type="text" placeholder="Email">But it’s missing a promise.
Now compare:
<label for="email">Email address</label>
<input id="email" type="email" name="email" required>That label is a binding agreement.
- Screen readers announce it
- Click targets expand
- Validation becomes meaningful
- Browsers can help users instead of guessing
When you omit labels, you’re basically saying, “The UI will figure it out”
Sometimes it does. Sometimes it critically fails its saving throw.
Lists Mean Something (Yes, Really)
I used to fake lists with paragraphs and line breaks.
<p>• Sword<br>• Shield<br>• Rope</p>Visually? Sure.
Semantically? Absolute goblin energy.
A real list:
<ul>
<li>Sword</li>
<li>Shield</li>
<li>Rope</li>
</ul>Now the browser understands:
- These items belong together
- Order (or lack of it) matters
- Navigation shortcuts apply
This is the contract paying dividends.
Buttons vs Links: Choose Your Weapon
One of the most common broken contracts I see:
<div onclick="submitForm()">Submit</div>Please. I beg you. Put the cursed item down.
Buttons do actions.
Links go places.
<button type="submit">Submit</button>
<a href="/inventory">View Inventory</a>This isn’t just semantics – it’s behavior baked into the platform:
- Keyboard support
- Focus states
- Default interactions
- Accessibility APIs
HTML already solved this. We just need to stop fighting it.
HTML Is the Dungeon Master You Can Trust
Here’s the quiet magic of good HTML:
When the structure is solid, everything else becomes easier.
CSS selectors are simpler.
JavaScript queries are clearer.
Refactors hurt less.
Accessibility stops feeling like a bolt-on tax.
It’s like having a DM who:
- Knows the rules
- Keeps consistent lore
- Doesn’t change mechanics mid-session
You stop compensating. You start building.
The Long Game: Future-You Is a Player Too
Every time I write clean HTML, I’m making a promise to future-me.
Six months from now.
After a framework upgrade.
During a bug hunt with cold coffee and low patience.
Semantic HTML reads like a map.
Div soup reads like a ransom note.
<article>
<header>
<h2>Post Title</h2>
<time datetime="2026-02-06">February 6, 2026</time>
</header>
<p>Content goes here.</p>
</article>That’s not just code.
That’s communication across time.
The D&D Analogy I Can’t Let Go Of
HTML is the rulebook.
CSS is flavor and presentation.
JavaScript is abilities and spells.
Frameworks are homebrew expansions.
If the rulebook is vague, every ruling becomes an argument.
If the rulebook is clear, the table relaxes and plays.
Structure isn’t boring.
Structure is how creativity survives contact with reality.
Final Thoughts from the DM’s Screen
I don’t rush past HTML anymore.
I slow down.
I name things properly.
I respect the contract.
Because HTML isn’t weak.
It’s foundational.
It’s honest.
It does exactly what it promises – no more, no less.
And in a world of abstractions stacked on abstractions, that kind of reliability?
That’s legendary-tier gear.
Roll structure.
Everything else gets a bonus.
