I was at my desk last Tuesday, halfway through a nasty WooCommerce checkout refactor, when my five-year-old niece wandered into the office. VS Code on one screen, a pile of unstyled <div> tags on the other. She stood there a second, tilted her head, and asked, “Wassat you typing?”
I usually go with “it’s for the computer,” but her curiosity stopped me this time. If I couldn’t explain HTML and CSS basics to a child, maybe I didn’t have as firm a grip on the why as I thought. It is easy to spend all day in React hooks and API endpoints and forget that the web is structure and paint.
The bricks and the paint: HTML and CSS basics
My first attempt was a total failure. I told her I was “semanticizing the markup to improve accessibility.” Her eyes glazed over. I felt like an idiot and had to pivot fast. Then I saw her LEGO set on the floor and it clicked. We were building a house, I said, and the stuff on the dark screen was the bricks.
HTML is the structure. It is the what-is-there. I showed her how I could tell the computer to put a roof (header), a floor (footer), and a couple of rooms (sections) on the screen. Take that away and there is no house. It is the same ground I covered in my WordPress development roadmap.
<!-- bbioon: The basic structure of our "house" -->
<div class="bbioon-house">
<header class="bbioon-roof">Roof</header>
<main class="bbioon-living-room">
<p>This is where we sit.</p>
<button class="bbioon-door">Open Door</button>
</main>
<footer class="bbioon-basement">Basement</footer>
</div>She watched me refresh the browser. “It’s ugly,” she said. She wasn’t wrong. Black text on a white void. So I explained CSS. If HTML is the bricks, CSS is the bucket of paint and the carpet. It is the how-it-looks. I could make the roof red and the door blue by writing a separate set of instructions.
/* bbioon: Making the house look like a house */
.bbioon-house {
border: 2px solid #333;
padding: 20px;
width: 300px;
}
.bbioon-roof {
background-color: #e74c3c; /* Red roof */
height: 50px;
color: white;
}
.bbioon-door {
background-color: #3498db; /* Blue door */
border: none;
color: white;
padding: 10px;
}The Feynman technique in the trenches
Stripping out the jargon reminded me of the Feynman Technique: if you can’t explain it simply, you don’t know it. Complex terms are comfortable, and we hide behind them. But when you are chasing a broken layout through a legacy codebase, you end up back at the fundamentals anyway.
I had been rushing lately, treating tags like chores instead of building blocks. Watching her react to a blue box appearing on screen reminded me why I started doing this 14 years ago. The web is literal and logical, something Rachel Andrew has argued for years in her writing on fundamental web design. Separation of concerns: structure on one side, style on the other.
A similar story on CSS-Tricks is what got me thinking about this in the first place, and it is worth rereading every few years. We argue about build tools for weeks while the browser is still only asking where the bricks go and what color to paint them.
So what came out of it
None of this is really about teaching kids. It is about clarity. Messy code usually means the logic underneath it is messy too. Three things I took away from an afternoon with a five-year-old:
- HTML is the skeleton. If the structure is weak, no amount of CSS “makeup” will fix it.
- CSS is the skin. Keep it separate, and do not let presentation logic bleed into the structure.
- Simple beats clever. If you cannot explain your solution to a non-dev, you are probably over-engineering it.
This gets complicated fast once you add layers of logic and dynamic data. If you are tired of debugging someone else’s “house” that is held together with duct tape and prayers, drop me a line. I have probably seen it before, and I usually know where the bricks are loose.
How would you explain a “race condition” or a “hook” to a five-year-old? I would like to hear your analogies.
