Semantic vs Non-Semantic HTML

Semantic elements describe their content's meaning. Non-semantic elements (<div>, <span>) describe nothing — they're pure, generic containers.

Side by Side

<!-- Non-semantic -->
<div class="top-bar">
    <div class="site-title">CodingNow</div>
    <div class="menu">
        <div class="menu-item"><a href="/">Home</a></div>
    </div>
</div>

<!-- Semantic -->
<header>
    <h1>CodingNow</h1>
    <nav>
        <a href="/">Home</a>
    </nav>
</header>

Both can be styled identically with CSS. Only the semantic version communicates real structure to a screen reader, a search engine, or a developer reading the code cold.

Non-Semantic Elements Still Have a Real Job

<div> and <span> aren't "bad" — they're the correct choice when content genuinely has no semantic meaning of its own, and exists purely for CSS/JavaScript hooks (a layout wrapper, a styling target). The mistake is using them when a semantic element would actually fit.

How to Decide

1. Does this content have a real, describable role (navigation, a self-contained article, a sidebar)? → Use the matching semantic element.
2. Is this purely a layout/styling wrapper with no inherent meaning? → <div> (block) or <span> (inline) is correct and appropriate.

Common Mistakes

• Treating "semantic HTML" as an all-or-nothing rule — real pages mix both, and that's correct
• Over-engineering with semantic tags where a simple div genuinely is the right tool

Interview Relevance

"Is it ever correct to use a div instead of a semantic element?" — yes, and being able to say when (pure layout, no inherent meaning) shows nuanced understanding, not just memorized rules.

Practice Question

Take the non-semantic example above and identify which non-semantic wrapper, if any, would still be legitimate to keep even after converting to semantic HTML.

Related HTML Notes

• Semantic HTML
• div vs section