LearnTo Close or Not To Close Tags in HTML5

Avatar

Jason Seifer
writes on August 24, 2012

In HTML5 it is not strictly necessary to close certain HTML tags. The tags that aren’t required to have specific closing tags are called “self closing” tags. What is a self closing tag? An example of a self closing tag is something like a line break (<br />) or the meta tag (<meta>). This means that the following are both acceptable:

<meta charset="UTF-8">
and
<meta charset="UTF-8" />

Some closing tags are optional, however. The tags are optional because it’s implied that a new tag would not be able to be started without closing it. These are the following:
html, head, body, p, dt, dd, li, option, thead, th, tbody, tr, td, tfoot, colgroup. There are also tags that are forbidden to be closed: img, input, br, hr, meta, etc.

The question is: should tags that are optional be closed? Code with closing tags is much more readable and easy to follow. It is much easier to visually inspect a page with well laid out markup. Working with this markup is easier for developers.

It makes little to no difference to a rendering engine in a browser that can parse markup written this way, so the tags can be considered redundant. For mobile users and browsers that can easily parse these pages, it is not necessary to close the tags. Not doing so can save on bandwidth as well. The problem arises when a browser is unable to parse markup written this way. The poor markup is still there.

The phrase “Be strict in what you send, but generous in what you receive” continues to apply. If your team is comfortable with that style of markup and the trade-offs then it may be acceptable. If your team prefers clean markup and will be visually inspecting markup most of the time, it is preferable to close tags even when not strictly necessary.

15 Responses to “To Close or Not To Close Tags in HTML5”

  1. I prefer to close all my tags, because that way my code oozes HTML/XHTML competence 🙂 Now seriously, I am all for closing all tags, because it is easier to process it in programs.

  2. Confused on March 2, 2016 at 1:53 pm said:

    You list as a self closing tag, and also as a tag which is forbidden to close

  3. “Code with closing tags is much more readable and easy to follow. It is much easier to visually inspect a page with well laid out markup. Working with this markup is easier for developers.”

    These are just statements not backed up by reasons or research. Is it more readable? For me it isn’t. My eye is distracted by the trailing slash. How does it impact visual inspection? How is it easier for developers?

    • obviously, you’re not a developer. if you try to debug html code with lots of nested tags, you’ll find out real quick if you need to close those tags.

      • Agree with Sean. Also, I have no trouble reading HTML if it is indented consistently.

        Anyway, explicitly closing void elements is an artifact of XML serialization, not HTML 5’s “html” serialization, so may introduce cognitive dissonance in many authors given that we are authoring html. Additionally, explicitly closing void elements was invalid in older versions of HTML, so more experienced developers are very used to implicitly closing void elements.

        Conversely, it may be the case that their omission impacts authors more used to writing XML, or HTML with an XML serialization. However as far as machines are concerned, they increase page weight with zero benefit.

  4. Matthew Holloway on May 7, 2013 at 8:50 pm said:

    I’m of the opinion that the words “tag” and “element” mean different things. Tag is the textural serialization (“start tag” and “end tag”), whereas an Element is a DOM node that is independent of the serialization.

  5. etc? bla

  6. I prefer closing the tag to make sure my code is future development proof. if in future i need to use the same code in XHTML application.

Learning to code can be fun!

Get started today with a free trial and discover why thousands of students are choosing Treehouse to learn about web development, design, and business.

Learn more