Html: Include, or Exclude, Optional Closing Tags

HTML: Include, or exclude, optional closing tags?

The optional ones are all ones that should be semantically clear where they end, without needing the end tag.
E.G. each <li> implies a </li> if there isn't one right before it.

The forbidden end tags all would be immediately followed by their end tag so it would be kind of redundant to have to type <img src="blah" alt="blah"></img> every time.

I almost always use the optional tags (unless I have a very good reason not to) because it lends to more readable and updateable code.

Omitting optional tags of html

Google are in a somewhat unusual situation in that they serve so very many copies of their main search pages that any tiny saving in page size soon add up. This means for them it's economical to make their pages smaller by removing close tags and whitespace, at the cost of making them harder to maintain.

You aren't Google; it's unlikely to pay off for you. You'll notice the Google page you link to itself doesn't omit the tags it recommends, because it's not one of the critical pages that Google serves a lot of. Compare that to the extreme minification of www.google.com front page.

Use gzip/deflate compression and you'll already get mostly minimal transfer size; reducing markup further is a desperate measure which unless you're serving loads will be a premature optimisation.

HTML Style Guide Google vs W3Schools (Omit Optional Tag)

Many times we use the optional closing tags because it makes the document more readable. As Google says, removing them reduces file size but, then, most of us don't have the traffic Google does. That suggestion is for those who do. Then, again, reducing download size is always a good thing.

I often leave out the body tag altogether because even the opening tag is optional in most cases. However, there is a danger that leaving that out, and leaving out closing tags, may cause issues later on. I would say putting body tags in and closing all elements removes the possibility of causing those issues. For example, you can only leave the html and body tags out under certain situations.

Reading the spec:

An html element's start tag can be omitted if the first thing inside
the html element is not a comment. An html element's end tag can be
omitted if the html element is not immediately followed by a comment.

For some, this is very important. To others it's not.

It can be more of an issue for dynamically generated sites where the content is created on the fly and the surrounding elements may not be known. Does one really know that the following element will cause a div element to be closed?

Do you need to close meta and link tags in HTML?

A tag must always be closed by the tag close symbol > (if we ignore certain SGML rules that nominally apply in non-XHTML HTML but were never implemented in browsers).

What you mean to ask is whether the elements need to be closed by end tags. The answer is that non-XHTML HTML (including HTML5 in HTML serialization), no end tag is required or allowed for meta and link elements. In practice, however, browsers just ignore explicit end tags for them, as well as the cargo-cult / before >, if you use them. And HTML5 makes this permissiveness a rule by even formally allowing the / in HTML serialization, too.

In XHTML, XML rules apply, so every element, without exception, must have both a start tag and an end tag, but the same tag may be used for both roles if the element content is empty, e.g. <meta name="foo" content="bar"/> as short for <meta name="foo" content="bar"></meta>. If you violate this when serving a document with an XML (XHTML) content type to a conforming browser, then your document is not displayed at all; an error message is shown instead.

When using an XHTML server with the HTML content type (Content-Type: text/html), as XHTML documents almost always are on the web, then browsers will actually apply the non-XHTML HTML rules.

To summarize:

• normally, use just <meta ...> with no /
• if you are really using XHTML in a context where XHTML parsing is actually applied, play by XML rules (and make sure you know them)
• if your boss tells you to write <meta ... />, do so; it’s not useful, but it causes no harm (except if you try to validate e.g. against the HTML 4.01 doctype).

Is there a list of all html tags that do not need a solidus or a closing tag?

You can extract a list from the WHATWG HTML Living Standard. Or, if you prefer, the W3C's HTML 5 Specification or the subsequent draft. According to Wikipedia, the conflict has somewhat recently been resolved in favour of WHATWG, so you probably want to go with the first one.

In any case, pay particular attention to the subheading "Tag omission in text/html" in each element description. But you need to read the document carefully to understand the ins and outs of HTML parsing.

Note: It's not just that end tags can be omitted. There are also elements whose open tag can be omitted. (The classic example is <tbody>, which is hardly ever physically present in an HTML document, but there are lots of others. <head>, for example.) The mere fact that an element's open tag has been omitted does not force the omission of the element's close tag, although it's pretty commonly the case. So you can't do it with just a list of omitable tags; you need to take element containment rules into account, too.

Also, even though the full parsing algorithm is suprisingly complicated even for valid documents, the standard algorithm and real-world HTML parsers are even more complicated, because they try to deal gracefully with web pages which don't conform to the standard.

What determines if an element needs a closing tag?

I was wondering what determines if an element needs a closing tag or not.

Their definition in the HTML specification.

but their structure is simply <element/>

The / is optional in HTML 5. It is only there for people who got used to the syntax when XHTML looked like the way forward.

Also, how would I replicate this behaviour in a custom element?

You can't. The custom element specification doesn't provide any means to make an end tag optional or forbidden.

Are (non-void) self-closing tags valid in HTML5?

• (Theoretically) in HTML 4, <foo / (yes, with no > at all) means <foo> (which leads to <br /> meaning <br>> (i.e. <br>>) and <title/hello/ meaning <title>hello</title>). I use the term "theoretically" because this is an SGML rule that browsers did a very poor job of supporting. There was so little support (I only ever saw it work in emacs-w3m) that the spec advises authors to avoid the syntax.

• In XHTML, <foo /> means <foo></foo>. This is an XML rule that applies to all XML documents. That said, XHTML is often served as text/html which (historically at least) gets processed by browsers using a different parser than documents served as application/xhtml+xml. The W3C provides compatibility guidelines to follow for XHTML as text/html. (Essentially: Only use self-closing tag syntax when the element is defined as EMPTY (and the end tag was forbidden in the HTML spec)).

• In HTML5, the meaning of <foo /> depends on the type of element:

  • On HTML elements that are designated as void elements (essentially "An element that existed before HTML5 and which was forbidden to have any content"), end tags are simply forbidden. The slash at the end of the start tag is allowed, but has no meaning. It is just syntactic sugar for people (and syntax highlighters) that are addicted to XML.
  • On other HTML elements, the slash is an error, but error recovery will cause browsers to ignore it and treat the tag as a regular start tag. This will usually end up with a missing end tag causing subsequent elements to be children instead of siblings.
  • Foreign elements (imported from XML applications such as SVG) treat it as self-closing syntax.

Do optional closing HTML tags (e.g. /TR) present extra cost to browser's HTML parser?

I created a bare HTML page with with an insane large table: 100,000 cells spread over 1000 columns and 100 rows, each filled with "x". The XHTML-valid one is about 10MB in size and the HTML-valid one is about 5MB in size. I tested it in 3 runs on FF 3.6.11 and IE8. Browsers are started clean on every run.

FF took on average 2 minutes and 5 seconds for the XHTML valid one and 1 minute and 15 seconds for the HTML valid one.

IE8 took on average 1 minute and 40 seconds for the XHTML valid one and the same time for the HTML valid one. It however ends up with a blank page on all occurrences.

Above results are open for further interpretation. To me, I would worry more about network bandwidth and maintainability than about browser's capabilities. Network bandwidth costs more $$$.

---

Related Topics