Three beginner mistakes in HTML

Practice finding and fixing these common problems

Browsers have a funny way of dealing with mistakes. If they can, they ignore problems and plow ahead.

In the not-so-distant past, there was a war between the people who wrote web standards (like HTML) and the people who wrote the web browsers. The web standards folk wanted browsers to be pickier, so that it would force web pages to become more virtuous. The web browser people just wanted everything to work for everybody as much of the time as possible, so that nothing ever looked broken. (Historical side note: the web standards people endorsed a standard called XHTML, while the web browser people picked a different standard called HTML5.)

In this battle, the browser builders won. As a result, browsers continue to ignore minor problems and many practices that were once considered mistakes are now allowed, with only a little bit of eyebrow raising. (Examples include leaving out the <head> section, writing tags in all capitals like <P>, and using standalone tags like <br> without closing them.)

But this article isn’t about best practices. It’s about a few showstopper mistakes that are easy to make and easy to fix. They’re the kind of mistakes that beginners make when they write their very first web pages. None of these mistakes will surprise you if you’ve used HTML for more than a week or two. But if you’re teaching the way of the web to someone new, these are good exercises to help them get started spotting problems.

How to use these examples

Mistakes are more fun when you get to figure them out yourself. This article has three examples of broken HTML. Each example is presented in an HTML pen (also known as a fiddle)— an interactive example that you can play with right in your browser. This allows you to see the result of the faulty markup, and make the minor changes that set it right.

These pens are hosted by the excellent CodePen service. Here’s how they work:

  • To run the pen, click the Run Pen button in the example box. You’ll see the web page appear in the box.
  • To take a look at the HTML for the pen, click the HTML button in the top-left corner of the example box. Now you’ll see the faulty markup.
  • To try your hand at fixing the problem, click “Edit on CodePen” in the top-right corner of the example box. This pops open a new browser tab where you see all the same stuff, but now you have the ability to change the HTML and see what happens.

CodePen is a great service for developing simple examples. If you’re a teacher, it lets you present problems to students and get them working right away, with no extra set up or file management. CodePen has plenty of other uses, too. It lets people share snippets of code, demonstrate examples in documentation, and challenge applicants in an interview.

1. The case of the disappearing text

The first example features two simple paragraphs of text from Alice’s Adventures in Wonderland. Or at least it should, because one of the paragraphs has vanished from sight.

Take a look at the markup. Is anything amiss? When you’re ready for answer, read on.

The culprit in this example is a missing angle bracket. Where you should have this:

<p>So she was considering in her own mind whether

You instead have something like this:

<p So she was considering in her own mind whether

Without the closing > in the tag <p>, the browser doesn’t know where the tag ends. Helplessly, it assumes that you mean to create a really long tag, something like <p So she was considering in her own mind whether ...>. And when text is part of a tag, it’s not part of the page content, so it doesn’t show up in the browser.

Once you recognize this headache, you’ll never fall victim to it again.

2. The case of the disappearing text II

The second example suffers from a similar problem. It’s meant to show two paragraphs of text, with a picture of zebras in between. But something goes wrong and the second paragraph disappears.

In this case the tag names and angle brackets are fine. The problem happens in the attributes that specify other details for an element. In this case, the element that’s at fault it the <img> element that shows the zebra picture. It has two attributes, a src attribute that points to the image file, and an alt attribute that describes the picture to search engines and screen readers. But the alt attribute is missing something crucial:

<img src="https://cdn.pixabay.com/photo/2017/08/22/11/43/zebra-2668655_640.jpg" alt="A crowd of zebras>

The alt attribute doesn’t end properly with a closing pair of quotation marks. As a result, the browser assumes the rest of the markup is all part of one giant attribute value (or at least until it encounters another " symbol somewhere else in the page).

Once again, it’s easy to find this problem if you start looking where the page goes wonky.

3. The case of the never-ending formatting

The final example features a similar slip up with a list of humorous definitions. There’s nothing missing from the page, but somehow the formatting isn’t quite what you expect. Halfway through the list, the italic formatting switches on for the word “Synonym” and — unexpectedly — stays on for the rest of the page.

If you look at the markup for the “Synonym” definition, things look straightforward enough — at first.

<p><i>Sock:</i> Something put between the foot and shoe.</p>
<p><i>Synonym:<i> The word you use instead of the word you can't spell.</i></p>

On closer inspection, you’ll see that the </i> end tag that should turn off italic formatting is actually missing its backlash. That mistake turns it into another <i> start tag, which means the browser turns on italic formatting again, even though it’s already on. And now, the italic formatting stays on until the browser hits an extra </i> to turn it off, which it doesn’t.


Now that you’ve got the idea, you can build a more complicated broken page, and challenge an HTML newbie to fix it. Because — as every seasoned coder knows — you learn more from fixing problems than from getting something right the first time.