To close or not to close

Have you ever wondered if it’s better to “close” a or tag like or if it’s better to just write in HTML5? Or why it’s not correct to write ? Well so have I, and my findings on the subject were a lot more interesting than I anticipated (if for some strange reason you find stuff like this interesting). br input If you are not interested in the whole story, just jump to the section «Validity» to get your answer. Void elements Void elements are a special kind of element that have content. That’s a big difference to other elements that be empty but can also contain other elements and text (such as s). must not can The most known void elements are: The lesser known are: That’s it. Those are of the existing void elements. all It is not, and has never been, valid HTML to write , since this would imply that the element accepts content (writing has absolutely no meaning). However, it is very common to see both and . br Hello! Although most people know that in HTML it is to write the rules for HTML are less obvious. X mandatory History To completely understand the rules of void elements a bit of history is necessary. , and are all based on , the Standard Generalized Language which has been crafted in 1986. HTML XML X(HT)ML SGML Markup and XML derived directly from SGML. XML is a more restrictive subset of SGML and that’s what XHTML is based on. HTML XHTML is basically the same as HTML but based on XML. So far so good? Then lets get to the interesting part: SGML has a feature called . This is a short notation to avoid having to close a tag when the content of your element is simple text. With you can write instead of . NET (Null End Tag) NET Quoted text As a side note, elements that do not contain any text, can be written as which is called and is the same as . Now, by that logic, if a void element does have a closing tag, would be interpreted as , and would be interpreted as which is obviously incorrect syntax. If you’re like me, you’re probably thinking «This is insane!». Unfortunately the authors of the HTML4 specification didn’t think so, which is why this is part of the specification. Apparently, the browser vendors at the time were not convinced as well, which resulted in very poor browser support (which, in this case, is arguably not a bad thing). not > XML (and thus XHTML) recognised the madness of such a syntax, and did not include the or the SHORTTAG NETENABL IMMEDNET «features», but provided a sane syntax for void elements, namely the that looks like this: . It seems very natural which is why most developers thought it was the right way to write it. NET Empty-Element tag Luckily HTML evolves and the people at the (who are drafting and setting the standards throughout the web) are learning from their past mistakes as well. Which is why HTML5 makes more sense. World Wide Web Consortium a lot Right in the , the W3C says: introduction of the new HTML5 syntax HTML 5 defines an HTML syntax that is compatible with HTML 4 and XHTML 1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML 4, such as the NET syntax (i.e. Hell yea Validity So back to the question of validity, the current is as follows: HTML5 specification for void elements Start tags consist of the following parts, in exactly the following order: A character. This means that the character has been rendered in HTML5, but it doesn’t add any meaning. There is between and . / optional absolutely no difference Correctness Well, for those of you who are really addicted to X(HT)ML, you might think, «yeah, it’s optional, but is still ‘more correct’», but I have to tell you: it is not. Actually, one might argue that adding to a void tag is an . The possibility to write it has mostly been added for compatibility reasons and every browser and parser should not handle and any differently. / ignored syntax error on that subject is also very clear that you should indeed close void tags. Google’s styleguide not Theoretical disadvantages Of course, not closing void tags has its disadvantages as well, but I think that they do not outweigh the advantage of having clean and terse void tags like . The first disadvantage of not closing void tags is that users need to have . If, for example, you don’t know what an element is, you might be confused if you can’t find any closing tags for it. But the list of void tags is very short and normally it’s quite obvious which tags are void tags. knowledge of the existing void tags The second disadvantage is that it gets more complicated for to get it right. They are required to know the complete list to properly interpret the code. If you write in an editor, it that there will never be a following that. editors and parsers has to know But this is more an issue related to the specification than to closing or not closing void tags, because is , so void elements require special treatment in any case. invalid My opinion on void tags I think that the whole concept of void tags could be avoided completely by using the content of some tags instead of defining additional attributes. Let’s take the tag for example. It has a attribute to add a description of the image, and for good reason: people who can’t see the image (either because they are physically incapable or because their device can’t display images) should have a way to know what is depicted (and if you’re adding an tag solely for design purposes then you’re doing something wrong anyway). So my question is: why isn’t the of the image tag the alternative tag? It seems rather obvious to me to write . The same goes for tags which even have a ! Why not just use the actual element content for that? should be as is the case with , etc… mandatory alt img content Image of doge content attribute Value content So really there are only a few void tags that should exist anyway, but obviously the W3C has to take backwards compatibility into account which makes changes of this kind much more difficult. Final thoughts: the tag The script tag has really been bothering me because it is such a verbose tag for such a simple directive. It seems wrong to write since the content of this tag has no logical correlation to (and the disallows to add both, content and the attribute). script my-script.js html specification src The problem is, that is a void tag since you can inline JavaScript on your page and there are no “optional void tags”. not Using the tag would have been perfect since it’s already used for other imports and provides all the attributes necessary to include external files. Of course, as so often in the web, the reason it is not used is backwards compatibility, since you would exclude all old browsers that don’t support that syntax.