Linking It All Together: <a>, Buttons & When JS Isn’t Necess

Let’s clear something up right away: <a> and <button> are not interchangeable. They might look the same once you slap some CSS on, but under the hood, they serve wildly different purposes. I remember when I styled a <button> to look like a link. It worked. Until it didn’t—like when users couldn’t right-click to open it in a new tab. Or when screen readers got confused. If you’ve ever felt unsure about which one to use, you’re not alone. So let's break this down and make your HTML more intuitive, accessible, and… dare I say it… professional.

The Link vs Button Cage Match

Here’s the golden rule I wish someone had tattooed on my brain when I started:

Use `<a>` for navigation — moving from one page or section to another. Use `<button>` for actions — triggering something on the current page (like opening a modal, submitting a form, toggling a menu).

And it’s not just semantics. It affects accessibility, expected behavior, and even browser features. For example:

          <!-- Correct usage -->
<a href="/projects">See My Projects</a>

<button type="button" onclick="toggleTheme()">Toggle Dark Mode</button>
        

That first one should be a link because it’s taking the user somewhere new. The second one performs an action in-place. Simple, right?

Now imagine swapping them. The link wouldn’t be focusable with keyboard shortcuts, and the button couldn’t open in a new tab. Suddenly your site’s usability tanks.

`href`, `target`, `rel`: The Hidden Trio

Let’s zoom in on the anatomy of a good <a> tag. Because yes, just dropping href="#" is lazy. And dangerous.

          <a href="https://jsbites.info" target="_blank" rel="noopener noreferrer">
  Visit JSBites
</a>
        

Here’s the breakdown:

• href — Required. Don’t even think about omitting this. It’s the destination.
• target="_blank" — Opens the link in a new tab. Use it thoughtfully; not everyone loves new tabs.
• rel="noopener noreferrer" — This is your security guard. It protects your page from performance and security issues when opening new tabs.

Mistake I made? Using target="_blank" without the rel. Once, a client’s site opened a malicious tab that hijacked the original window. Oops. Lesson learned.

Building a Real Nav That Works Without JS

Okay, back to our course project. Time to build a real, functioning site nav — using only HTML. No JavaScript. Just raw, beautiful markup.

Here’s what we’ll drop into our header:

          <header>
  <nav>
    <ul>
      <li><a href="/index.html">Home</a></li>
      <li><a href="/about.html">About</a></li>
      <li><a href="/projects.html">Projects</a></li>
      <li><a href="/contact.html">Contact</a></li>
    </ul>
  </nav>
</header>
        

Some things to note:

• <ul> keeps it semantically correct and screen-reader friendly.
• Each <a> points to a real destination.
• No buttons, no dropdowns, no magic. It just works.

Later we’ll layer on some JavaScript for extra interactivity—like mobile nav toggles—but your base should always function without it. That's good UX. That's accessible design. And that’s how HTML is meant to work.

What’s Next?

You’ve built pages. You’ve linked them together. Now it’s time to let your visitors talk back. In the next lesson, we’ll dive into forms that don’t suck—complete with labels, inputs, and a legit Contact page that feels like a human wrote it. Get started here: Forms Without Tears: Labels, Inputs & the Contact Page.