Back to HTML for JavaScript Developers: Build the Bones

Validating, Cleaning & Prepping Your HTML for the Real World

So here we are. You’ve built a complete multi-page HTML site, written semantic markup, and even made it accessible without touching a single line of JavaScript. If you’re anything like me, you’re tempted to jump right into CSS now and start making things pretty. But hold up—before we slap on that fresh coat of style, we need to clean our HTML house. Because trust me, nothing sucks more than debugging layout problems later only to find you forgot to close a <div> or misused a tag. Been there. Multiple times. Let’s prep this thing like professionals.

W3C Validator: The Good, The Bad, The Confusing

The W3C Validator is the internet’s equivalent of spellcheck for HTML. Feed it your code, and it’ll tell you what’s broken, what’s suspicious, and what’s fine but maybe weird.

Here’s how to use it:

  • Paste in your HTML, or upload the file.
  • Run the check.
  • Read every warning and error.

You’ll see things like:

  • Element “main” not allowed as child of element “span”.
  • Stray end tag “footer”.
  • Attribute “autofocus” not allowed on element “textarea” at this point.

Fix them. All of them. Even the confusing ones. Google is your friend here, or MDN Web Docs if you want actual trustworthy info.

A clean validation report is a good sign that your site’s HTML is structurally sound. It’s also a green light for browser consistency and assistive tech.

But don’t treat it like gospel. If it complains about a valid use case (it happens), make an informed decision. Sometimes, the validator’s just being pedantic.

Prepping for CSS: Class Names, IDs, and Data Attributes

Now’s the time to go through your markup and make sure it’s ready for styling. This isn’t just about slapping on random classes—it’s about choosing selectors that’ll help you write clean, reusable CSS.

Class Names

Use class names for styling elements you’ll reuse across pages:

html
1
2
3
          <section class="project-card">
  <h2 class="project-title">Weather App</h2>
</section>

Avoid class names like blue-text or margin-top-20. That’s styling in disguise. Go with names that describe what the thing is, not how it looks.

IDs

Use id sparingly. Mostly for:

  • Page anchors
  • Form inputs (<label for="email">)
  • JavaScript hooks (eventually)

Never use id for styling unless you really know what you’re doing. Specificity hell is real.

Data Attributes

Planning to pass data around or add interactivity later? Start using data-* attributes:

html
1
          <button data-project-id="42">View Details</button>

These won’t interfere with CSS but give you flexibility when JS enters the picture.

Export Your Work Like a Boss

Your HTML should be ready for action. Here’s a checklist before moving on:

  • Do all pages link to each other?
  • Is the tab order logical?
  • Did you run the W3C validator and fix issues?
  • Do all images have alt text?
  • Are all headings structured properly?
  • Did you keep the code readable with indentation and spacing?
  • Do filenames and folder paths make sense? (about.html, not page2.html)

If yes: zip up your folder. You now have a production-ready, human-friendly, browser-consistent HTML site. That’s no small feat.

Here’s what your file structure might look like:

bash
1
2
3
4
5
6
7
8
9
10
          /my-html-site
├── index.html
├── about.html
├── projects.html
├── contact.html
├── images/
│   └── profile.jpg
├── svg/
│   └── logo.svg
└── styles/  <-- empty for now, but not for long

Clean, semantic, accessible. That’s how we do it here.

What’s Next?

You’ve mastered the bones. Now it’s time for muscle and skin. The next course—CSS for JavaScript Developers: Design Without Fear—is where you’ll learn to style everything you just built, the right way. No Bootstrap. No frameworks. Just you, the cascade, and real-world design decisions. See you there.