Guess what, you're not required to open <html>, <head>, or <body> either. It all follows from SGML tag inference rules, and the rules aren't that difficult to understand. What makes them appear magical is WHATWG's verbose ad-hoc parsing algorithm presentation explicitly listing eg. elements that close their parents originally captured from SGML but having become unmaintained as new elements were added. This already started to happen in the very first revision after Ian Hickson's initial procedural HTML parsing description ([1]).
I'd also wish people would stop calling every element-specific behavior HTML parsers do "liberal and tag-soup"-like. Yes WHATWG HTML does define error recovery rules, and HTML had introduced historic blunders to accomodate inline CSS and inline JS, but almost always what's being complained about are just SGML empty elements (aka HTML void elements) or tag omission (as described above) by folks not doing their homework.
Serious question: why would you ever want to not close tags? It saves a couple of key strokes, but we have snippets in our editors, so the amount of typing is the same. Closed tags allow editors like Vim or automated tools to handle the source code easier; e.g. I can type `dit` in Vim to delete the contents of a tag, something that's only possible because the tag's content is clearly delimited. It makes parsing HTML easier because there are fewer syntax rules.
I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have. HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML. Even though I don't have to, I strive to adhere to the stricter rules of closing all tags, closing self-closing tags and only using lower-case tag names.
Why did markdown become popular when we already have html? Because markdown is much easier to write by hand in a simple text editor.
Original SGML was actually closer to markdown. It had various options to shorten and simplify the syntax, making it easy to write and edit by hand, while still having an unambiguous structure.
The verbose and explicit structure of xhtml makes it easier to process by tools, but more tedious for humans.
Personally I think Markdown got _really_ popular not because it is easier to write but because it is easier to read.
It’s kind of a huge deal that I can give a Markdown file of plain text content to somebody non-technical and they aren’t overwhelmed by it in raw form.
I've been closing my tags for 30 years and I assume that I will for the rest of my days. I like that it validates as XML. Historically I used XSLT a LOT.
Imho the real strength of markdown is it forces people to stick to classes instead of styling. "I want to write in red comic Sans" " I don't care, you can't".
And markdown tables are harder to write than HTML tables. However, they are generally easier to read. Unless multi line cell.
> I never understood why the more strict rules of XML for HTML never took off
Internet Explorer failing to support XHTML at all (which also forced everyone to serve XHTML with the HTML media type and avoid incompatible syntaxes like self-closing <script />), Firefox at first failing to support progressive rendering of XHTML, a dearth of tooling to emit well-formed XHTML (remember, those were the days of PHP emitting markup by string concatenation) and the resulting fear of pages entirely failing to render (the so-called Yellow Screen of Death), and a side helping of the WHATWG cartel^W organization declaring XHTML "obsolete". It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax.
I think most of those are actually no longer relevant, so I still kind of hope that XHTML could have a resurgence, and that the tag-soup syntax could be finally discarded. It's long overdue.
What I never understood was why, for HTML specifically, syntax errors are such a fundamental unsolvable problem that it's essential that browsers accept bad content.
Meanwhile, in any other formal language (including JS and CSS!), the standard assumption is that syntax errors are fatal, the responsibility for fixing lies with the page author, but also that fixing those errors is not a difficult problem.
Your premise is not correct because you're not aware that other data formats also have parsers that accept malformed content. Examples:
- pdf files: many files with errors can be read by Adobe Acrobat. And code PDF libraries for developers often replicate this behavior so they too can also open the same invalid pdf files.
- zip files. 7-Zip and WinRAR can open some malformed zip files that don't follow the specification. E.g. 7-Zip has extra defensive code that looks for a bad 2-byte sequence that shouldn't be there and skips over it.
- csv files. MS Excel can read some malformed csv files.
- SMTP email headers: Mozilla Thunderbird, MS Outlook, etc can parse fields that don't exactly comply with RFC 822 -- make some guesses -- and then successfully display the email content to the user
The common theme to the above, including HTML... the Raw Content is more important than a perfectly standards-compliant file format. That's why parsers across various domains make best efforts to load the file even when it's not 100% free of syntax errors.
HTML is a markup language to format text, not a programming or data serialization language so end users have always preferred to see imperfectly coded or incompletely loaded web pages imperfectly rendered over receiving a failure message, particularly on 90s dialup. Same applies to most other markup languages.
The web owes its success to having low barriers to entry and very quickly became a mixture of pages hand coded by people who weren't programmers, content produced by CMS systems which included stuff the content author didn't directly control and weren't necessarily reliable at putting tags into the right place, and third party widgets activated by pasting in whatever code the third party had given you. And browsers became really good at attempting to rendering erroneous and ambiguous markup (and for that matter were usually out of date or plain bad at rigidly implementing standards)
There was a movement to serve XHTML as XML via the application/xhtml+xml MIME type never took off because browsers didn't do anything with it except loading a user-hostile error page if a closing tag was missed (or refusing to load it at all in the case of IE6 and older browsers), and if you wanted to do clever transformation of your source data, there were ways to achieve that other than formatting the markup sent to the browser as a subset of XML
It's mostly historical. Browsers accepted invalid HTML for 10 years, there's a lot of content authored with that assumption that's never going to be updated, so now we're stuck with it.
We could be more strict for new content, but why bother if you have to include the legacy parser anyway. And the HTML5 algorithm brings us most of the benefits (deterministic parsing) of a stricter syntax while still allowing the looseness.
> never going to be updated, so now we're stuck with it.
Try going to any 1998 web page in a modern browser... It's generally so broken so as to be unusable.
As well as every page telling me to install flash, most links are dead, most scripts don't run properly (vbscript!?), tls versions now incompatible, etc.
We shouldn't put much effort into backwards compatibility if it doesn't work in practice. The best bet to open a 1998 web page is to install IE6 in a VM, and everything works wonderfully.
The vast majority of pages from 1998 work fine today. VBscript was always a tiny minority of scripting. And link rot is an undeniable problem but that’s not an issue with the page itself.
You’re unlikely to find a 1998-era Web page still running a 1998-era SSL stack. SSL was expensive (computationally and CA-cartel-ically), so basically banks and online shopping would have used SSL back then.
Syntax errors are not fatal in CSS. CSS has detailed rules for how to handle and recover from syntax errors, usually by skipping the invalid token. This is what allows introducing new syntax in a backwards-compatible manner.
Because HTML is designed to be written by everyone, not just “engineers” and we’d rather be able to read what they have to say even if they get it wrong.
I was there, Gandalf. I was there 30 years ago. I was there when the strength of men failed.
Netscape started this. NCSA was in favor of XML style rules over SGML, but Netscape embraced SGML leniency fully and several tools of that era generated web pages that only rendered properly in Netscape. So people voted with their feet and went to the panderers. If I had a dollar for every time someone told me, “well it works in Netscape” I’d be retired by now.
> It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax.
Well, this is not entirely true: XML namespaces enabled attaching arbitrary data to XHTML elements in a much more elegant, orthogonal way than the half-assed solution HTML5 ended up with (the data-* attribute set), and embedding other XML applications like XForms, SVG and MathML (though I am not sure how widely supported this was at the time; some of this was backported into HTML5 anyway, in a way that later led to CVEs). But this is rather niche.
I would argue the stricter rules did take off, most people always close <p>, it's pretty common to see <img/> over <img>—especially from people who write a lot of React.
But.
The future of HTML will forever contain content that was first handtyped in Notepad++ in 2001 or created in Wordpress in 2008. It's the right move for the browser to stay forgiving, even if you have rules in your personal styleguide.
Because I want my hand-written HTML to look more like markdown-style languages. If I close those tags it adds visual noise and makes the text harder to read.
Besides, at this point technologies like tree-sitter make editor integration a moot point: once tree-sitter knows how to parse it, the editor does too.
A lot of HTML tags never have a body, so it makes no sense to close them. XML has self-closing tag syntax but it wasn't always handled well by browsers.
A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends. Closing li also creates the opportunity for nonsensical content inside of a list but not in any list item. Of course all of these corner cases are now well specified because people did close their tags sometimes.
> A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends
While this is true I’ve never liked it.
<p>blah<p>blah2</p>
Implies a closing </p> in the middle. But
<p>blah<span>blah2</p>
Does not. Obviously with the knowledge of the difference between what span and p represent I understand why but in terms of pure markup it’s always left a bad taste in my mouth. I’ll always close tags whenever relevant even if it’s not necessary.
This interpretation of the p element implies that it contains a paragraph. But HTML is first and foremost a document format, and one could just as logically conclude that the p element simply starts a new paragraph. Under the latter interpretation, </p> would never exist any more than </hr> or </img>.
In practice, modern HTML splits the difference with rigorous and well defined but not necessarily intuitive semantics.
I was going to respond that HTML was the original syntax and XML the usurper, but a comment in another thread casts some doubt on that version of events: https://news.ycombinator.com/item?id=46576844
In the case of <br/> and <img/> browsers will never use the content inside of the tag, so using a closing tag doesn't make sense. The slash makes it much clearer though, so missing it out is silly.
"Self-closing tags" are not a thing in HTML5. From the HTML standard:
> On void elements, [the trailing slash] does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
It was mainly added to HTML5 to make it easier to convert XHTML pages to HTML5. IMO using the trailing slash in new pages is a mistake. It makes it appear as though the slash is what closes the element when in reality it does nothing and the element is self-closing because it's part of a hardcoded set of void elements. See here for more information: https://github.com/validator/validator/wiki/Markup-%C2%BB-Vo...
It's not a mistake if you want to be able to use XML tools on your HTML. It's basically no effort to make HTML also be valid XML so you'd might as well get the additional tooling compatibility and simplicity for free. For the same reason, it's courteous toward others.
Self-closing tags do nothing in HTML though. They are ignored. And in some cases, adding them
obfuscates how browser’s will actually interpret the markup, or introduce subtle differences between HTML and JSX, for example.
How does the slash make it clearer? It's totally inert, so if you try to do the same thing with a non-void tag the results will not be what you expect!
It indicates that the content that follows is not inside of the tag without the reader needing to remember how HTML works. Tags should have either a self-closing slash, or a closing tag.
The third way of a bare tag is where the confusion comes from.
It doesn't indicate that, though. If you write <div />, for example, the content that follows is inside of the tag. So the reader still needs to remember how HTML works, because the slash does nothing.
Contrary to <img /> or <br />, <div /> is necessarily a mistake or intentionally misleading. The unfamiliar reader should not stumble upon <div /> too often. <div /> is a bug. It's a bit like using misleading indentation in C-like programming languages. Yeah, it can happen, and is a source of bugs, but if the page is well written, the regularity of having everything closed, even if it's decorative for the spec, can help the unfamiliar reader who doesn't have all the parsing rules in mind.
Now, we can discuss whether we should optimize for the unfamiliar reader, and whether the illusion of actual meaning the trailing slash in HTML5 can be harmful.
I would note that exactly like trailing slashes, indentation doesn't mean anything for the parser in C-like languages and can be written misleadingly, yet we do systematically use it, even when no unfamiliar reader is expected.
At this point, writing a slash or not and closing all the tags is a coding style discussion.
Now, maybe someone writing almost-XHTML (closing all tags, putting trailing slashes, quoting all the attributes) should go all the way and write actual XHTML with the actual XHTML content type and benefit from the strict parser catching potential errors that can backfire and that nobody would have noticed with the HTML 5 parser.
Because browsers close some tags automatically. And if your closing tag is wrong, it'll generate empty element instead of being ignored. Without even emitting warning in developer console. So by closing tags you're risking introducing very subtle DOM bugs.
If you want to close tags, make sure that your building or testing pipeline ensures strict validation of produced HTML.
Netscape Navigator did, in fact, reject invalid HTML. Then along came Internet Explorer and chose “render invalid HTML dwim” as a strategy. People, my young naive self included, moaned about NN being too strict.
NN eventually switched to the tag soup approach.
XHTML 1.0 arrived in 2000, attempting to reform HTML by recasting it as an XML application. The idea was to impose XML’s strict parsing rules: well-formed documents only, close all your tags, lowercase element names, quote all attributes, and if the document is malformed, the parser must stop and display an error rather than guess. XHTML was abandoned in 2009.
When HTML5 was being drafted in 2004-onwards, the WHATWG actually had to formally specify how browsers should handle malformed markup, essentially codifying IE’s error-recovery heuristics as the standard.
But not closing <p> etc has always been valid HTML. Back from SGML it was possible for closing tags to be optional (depending on the DTD), and Netscape supported this from the beginning.
Leaving out closing tags is possible when the parsing is unambigous. E.g <p>foo<p>bar is unambiguous becuse p elements does not nest, so they close automatically by the next p.
The question about invalid HTML is a sepearate issue. E.g you can’t nest a p inside an i according to the spec, so how does a browser render that? Or lexical error like illegal characters in a non-quoted attribute value.
This is where it gets tricky. Render anyway, skip the invalid html, or stop rendering with an error message? HTML did not specify what to do with invalid input, so either is legal. Browsers choose to go with the “render anyway” approach, but this lead to different outputs in different browsers, since it wasn’t agreed upon how to render invald html.
The difference between Netscape and IE was that Netscape in more cases would skip rendering invalid HTML, where IE would always render the content.
The article itself falsifies this explanation; IE wasn't released until August 1995. The HTML draft specs published prior to this already specified that these tags didn't need closing; these simply weren't invalid HTML in the first place.
The oldest public HTML documentation there is, from 1991, demonstrates that <li>, <dt>, and <dd> tags don't need to be closed! And the oldest HTML DTD, from 1992, explicitly specifies that these, as well as <p>, don't need closing. Remember, HTML is derived from SGML, not XML; and SGML, unlike XML, allows for the possibility of tags with optional close. The attempt to make HTML more XML-like didn't come until later.
Former NCSA employee here. The fuck they did. Netscape caught us out time and again for accepting SGML garbage that we didn’t handle properly. It’s a big part of why Netscape won that round of the browser wars. Such recovery then wound up in tools that generated web pages for you and it was all over but the crying. JavaScript was just the last straw. Which I tried to talk them into adopting but got no traction.
Optinal tags have always been allowed in HTML, for the simple if debatable reason (hence xhtml) that some humans still author documents by hand, knowingly skip md et al _and_ want to write as few characters as possible (I do!).
This is clear in Tim Berners-Lee's seminal, pre-Netscape "HTML Tags" document [0], through HTML 4 [4] and (as you point out) through the current living standard [5].
I didn't know that Navigator was ever strict, and bit funny story about when I complained that they hadn't been strict...
Around 2000, I was meeting with Tim Berners-Lee, and I mentioned I'd been writing a bunch of Web utility code. He wanted to see, so I handed him some printed API docs I had with me. (He talked and read fast.)
Then I realized he was reading the editorializing in my permissive parser docs, about how browser vendors should've put a big error/warning message on the window for invalid HTML.
Which suddenly felt presumptuous of me, to be having opinions about Web standards, right in front of Tim Berners-Lee at the time.
(My thinking with the prominent warning message that every visitor would see, in mid/late-'90s, was that it would've been compelling social pressure at the time. It would imply that this gold rush dotcom or aspiring developer wasn't good at Web. Everyone was getting money in the belief that they knew anything at all about Web, with little way to evaluate how much they knew.)
I have bad memories of Netscape 4 and IE4 (I think those were the versions) which both allowed invalid HTML but had different rules for doing it. Accidentally missed off a closing table tag once, and one browser displayed the remainder of the page, but the other didn't.
Wouldn't this still result in just two paragraph elements? Yes, the first gets auto-closed, but I don't see how a third paragraph could emerge out of this. Surely that closing tag should just get discarded as invalid.
edit: Indeed, it creates three: the </p> seems to create an empty paragraph tag. Not the first time I've been surprised by tag soup rules.
Browser will parse that as three HTMLParagraphElements. You may think that's invalid HTML, but browser will parse it and won't indicate any kind of error.
> Browser will parse that as three HTMLParagraphElements
Why?
> You may think that's invalid HTML, but browser will parse it and won't indicate any kind of error.
It isn’t an opinion, it literally is invalid HTML.
What you’re responding to is an assumption that I was suggesting browsers couldn’t render that. Which isn’t what I claimed at all. I know full well that browsers will gracefully handle incorrect HTML, but that doesn’t mean that the source is magically compliant with the HTML specification.
I don't know why. Try it out. That's the way browsers are coded.
> It isn’t an opinion, it literally is invalid HTML.
It matters not. You're writing HTML for browser to consume, not for validator to accept. And most of webpages are invalid HTML. This very HN page contains 412 errors and warnings according to W3C validator, so the whole point of HTML validness is moot.
> I’m not saying you’re wrong, but I’d need more than that to be convinced. Sorry.
So basically my point is:
1. You can avoid closing some tags, letting browser to close tags for you. It won't do any harm.
2. You can choose to explicitly close all tags. It won't do anything for valid HTML, but it'll introduce subtle and hard to find DOM bugs by adding empty elements.
So you're trying to improve HTML source readability by risking to introduce subtle bugs.
If you want to do that, I'd recommend to implement HTML validation for build or test pipeline at least.
Another alternative is to use HTML comments to close tags, as this closing tag is supposed to be documentation-only and won't be used by browser in a proper code.
I get your point, but again, that’s not relevant to the point I was making.
You posted a terse comment with some HTML. I responded specifically about that comment and HTML. And you’re now elaborating on things as a rebuttal to my comment despite the fact that wasn’t the original scope of my comment.
Another example of that is how you’ve quoted my reply to the 2 vs 3 elements, and then answered a completely different question (one I didn’t even ask).
I don’t think you’re being intentionally obtuse but it’s still a very disingenuous way to handle a discussion.
My point is that by closing optional tags you can introduce subtle bugs into your layout that might take some time to find and browser won't be of any help. You write closing tag, browser will implicitly add starting tag. It's better to memorise which tags are optional and do not close them at all.
Precisely, it's an added burden to remember and what might be skipped. The less many exception, the better.
Though if a linter is formatting the whole codebase on its own in an homogeneous way, and someone else will deal with the added parsing complexity, that might feel okayish also to me.
Generally speaking, the less clutter the better. A bit like with a js codebase which is semicolon free where possible.
For pleasant experience of read and write, html in a simple text editor is very low quality. Pug for example is bringing far less clutter, though mandatory space indentation could be avoided with some alternative syntactic choices.
They are not nested, according to HTML5 parsing rules. You get 3 (yes, three) sibling paragraphs, including an empty one.
There being nesting is just implied by the closing tags and indentation. But it is not actually there. I think this is the point of the example: Adding the closing tags just confuses the reader, by implying nesting that is not actually there, and even introduces a third empty paragraph. It might be better left out entirely.
Even though it arguably should be, according to HTML5 parsing rules, this is not invalid. It is just interpreted differently from
what most people would probably expect.
I think this is the point of the example, afaiui: The closing tags don’t clarify anything, quite the contrary, actually. They serve only to confuse the reader.
I tried using XHTML when we were told, loudly and repeatedly, that it was the inevitable future. Thank god it wasn’t.
You should close your tags. It’s good hygiene. It helps IDEs help you. But. Trust me, you do not want the browser enforcing it at runtime, lest your idea of fun is end users getting helpful error messages like an otherwise blank screen saying “Invalid syntax”.
For fun, imagine that various browsers are not 100.00% compatible (“Inconceivable!”), so that it wasn’t possible to write HTML that every browser agreed was completely valid. Now it’s guaranteed that some of your users will get the error page, even when you’re sure your page is valid.
Conceptually, XHTML and its analogs are better. In practice, they’re much, much worse.
My experience with parsing html gathered from the wild is you're pretty much not required to do anything. "Go wild" and "have fun" seem to be the mottoes.
How does all this interact with html minification? IIRC you can't nest p tags but you can nest li, so does browser just make assumptions about your intent. Is it not better to state your intent as clearly as possible if not for a browser, then for the next developer?
Perhaps the most distinguishing characteristic of HTML5 is that it specifies exactly what to do with tag soup. The rules are worth a glance at some time, just to see how rather absurdly complicated they are to do the job of picking up the pieces of who knows how many terabytes and petabytes of garbage HTML were generated before they were codified in an attempt to remain backwards compatible with the various browsers prior to that. And then you'll understand why I'm not going to even begin to attempt to answer your question about how browsers handle various tag combinations. Instead my point is only that, with HTML5, there is in fact a very concrete answer that is no longer up to the browsers trying to each individually spackle over the various and sundry gaps in the standards.
But honestly no answer to "what does the browser do with this sort of thing" fits into an HN comment anymore. I'm glad there's a standard, but there's a better branch of the multiverse where the specification of what to do with bad HTML was written from the beginning and is much, much simpler.
Works fine on every browser I've thrown at it. Even Gnome Web (WebKit) allows scrolling just fine. Sounds like a Safari bug? Maybe a content blocker interfering with the page?
Yeah but it's better for your mental sanity. It's not just a habit, the closure reduces the mental load and helps to keep track of structure in the messy world of html documents. So it is actually more efficient
It depends completely on how nested your HTML tags are.
I hand write my HTML sometimes, and in those cases it’s often very basic documents consisting of maybe an outer container div, a header and a nav with a ul of li for the navigation items and then an inner container div and maybe an article element, and then the contents are mostly p and figure elements and various level headings.
In this case, there is no mental overhead of omitting closing li and closing p at the end of the line, and I omit them because I am allowed to and it’s still readable and fine.
Whether you can or can't omit a closing element is one thing, but it seems like a useful thing to be able to quickly determine if some content is inside or outside a tag, so why complicate things?
(This is especially relevant with "void" tags. E.g. if someone wrote "<img> hello </img>" then the "hello" is not contained in the tag. You could use the self closing syntax to make this more obvious -- Edit: That's bad advice, see below.)
The inert self closing syntax is misleading, though, because if you use it for a non-void element then whatever follows will be contained within the tag.
e.g. how do you think a browser will interpret this markup?
<div />
<img />
A lot of people think it ends up like this (especially because JSX works this way):
I get why you may not close <img> or <br> since they don't contain anything inside, but <p> and <li> should be closed to indicate the end of the content, otherwise it's shows you are mentally lazy and relying on some magic to do the work and guess what you wanted
<p> indicates a new paragraph. <li> indicates a new list item. Unless otherwise specified, the existing paragraph/list item continues. There's nothing magic about any of this, it's part of the HTML spec.
Laziness doesn't play a role. This isn't XML where you need to repeat yourself over and over again or abusing a bug in the rendering logic; it's following the definitions markdown language you're writing content in.
If you're not too familiar with the HTML language then it's always a safe bet to close your tags, of course.
To each their own. In simple lists for navigation menus I always omit closing li. There is no ambiguity on what I am intending even with those closing li omitted in such simple cases:
I know some (or even the official?) JavaDoc style guidelines require <p> woithout closing counterparts. But to me this feels the same as omitting semicolins in JS -yes, xou can get away with it, but it's bad style in my opinion.
Article actually argues/states that a lot of the times not closing elements is more readable. It mentions tables without a concrete example, but I think e.g.
is valid and reads better than if the row and data elements were closed (and on separate rows because it would be too much noise otherwise) (of course the whitespaces are different, if they matter for some reason). For a 3x3 table 5 lines vs ~15 lines.
I don’t think tables are human readable in any machine readable format, not even markdown.
The problem is when you have long cells that you’d normally word wrap inside the cell, everything else ends up misaligned in your markup language. Or when you need to add styling to text in a cell, suddenly it’s unreadable again. Or when there’s more than a small few number of columns thus causing each row to word wrap inside your IDE, etc
I think it makes far more sense to just acknowledge that tables are going to ugly, compose them elsewhere, and then export them to your markup language following that language’s specification strictly.
> Browsers do not treat missing optional end tags as errors that need to be recovered from
Just because it worked on the one browser you tested it on, doesn't mean it's always worked that way, or that it will always work that way in the future...
Every browser treats html/etc differently... I've run into css issues before on Chrome for android, because I was writing using Chrome for desktop as a reference.
You'd think they should be the same because they come from the same heritage, but no...
> Just because it worked on the one browser you tested it on, doesn't mean it's always worked that way, or that it will always work that way in the future...
All browsers have worked this way for decades. It’s standard HTML that has been in widespread use since the beginning of the web. The further back you go, the more normal it was to write HTML in this style. You can see in this specification from 1992 that <p> and <li> don’t have closing tags at all:
Maybe there were obscure browsers that had bugs relating to this back in the mid 90s, but I don’t recall any from the late 90s onwards. Can you name a browser released this millennium that doesn’t understand optional closing tags?
The author has a point, but I object to this mischaracterization:
> XHTML, being based on XML as opposed to SGML, is notorious for being author-unfriendly due to its strictness
This strictness is a moot point. Most editors will autocomplete the closing tag for you, so it's hardly "unfriendly". Besides, if anything, closing tags are reader-friendly (which includes the author), since they make it clear when an element ends. In languages that don't have this, authors often add a comment like `// end of ...` to clarify this. The article author even acknowledges this in some of their examples ("explicit end tags added for clarity").
But there were other potential benefits of XHTML that never came to pass. A strict markup language would make documents easier to parse, and we wouldn't have ended up with the insanity of parsing modern HTML, which became standardized. This, in turn, would have made it easier to expand the language, and integrate different processors into the pipeline. Technologies like XSLT would have been adopted and improved, and perhaps we would have already had proper HTML modules, instead of the half-baked Web Components we have today. All because browser authors were reluctant to force website authors to fix their broken markup. It was a terrible tradeoff, if you ask me.
So, sure, feel free to not close HTML tags if you prefer not to, and to "educate" everyone that they shouldn't either. Just keep it away from any codebases I maintain, thank you very much.
To be fair, I don't mind not closing empty elements, such as `<img>` or `<br>`. But not closing `<p>` or `<div>` is hostile behavior, for no actual gain.
> On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
For ebook production, you need to use xhtml, the epub standard is defined that way. And it is indeed useful to be able to treat them as xml files and use xslt and xquery, etc. with them.
> "Did you forget to close your p tags or is that on purpose?"
> [...]
> These are all adapted from real comments;
If that's a comment you get, write better code. It does not matter to me whether closing p-tags is mandatory or optional. If you don't do it, I don't want you working on the same code base as me.
This kind of knowledge makes for fun blog posts, but if people direct these kind of comments to me. You're obviously using your knowledge to just patronize and lecture people.
This a very verbose and confuse article. Mixing P/LI and IMG/BR is wrong. I think the situation could be explained with two points:
1. The autoclose syntax does not exist in HTML5, and a trailing slash after a tag is always ignored. It's therefore recommended to avoid this syntax. I.e write <br> instead of <br />. For details and a list of void elements, see https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme...
2. It's not mandatory to close tags when the parser can guess where they end. E.g. a paragraph cannot contain any line-block, so <p>a<div>b</div> is the same as <p>a</p><div>b</div>. It depends on the context, but putting an explicit end tag is usually less error-prone.
Putting an explicit end tag is more error-prone. It won't do anything for valid HTML but it'll add empty tag for invalid HTML. If you want to improve human readability, put end tag enclosed in HTML comment. At least it won't add empty elements.
There are ways for not closing HTML tags to backfire in some scenarios.
Some rules of thumb, perhaps:
— Do not omit if it is a template and another piece of HTML is included in or after this tag. (The key fact, as always, is that we all make errors sometimes—and omitting a closing tag can make an otherwise small markup error turn your tree into an unrecognisable mess.)
— Remember, the goal in the first place is readability and improved SNR. Use it only if you already respect legibility in other ways, especially the lower-hanging fruit like consistent use of indentation.
— Do not omit if takes more than a split-second to get it. (Going off the HTML spec, as an example, you could have <a> and <p> as siblings in one container, and in that case if you don’t close some <p> it may be non-obvious if an <a> is phrasing or flow content.)
The last thing you want is to require the reader of your code to be more of an HTML parser than they already have to be.
For me personally this makes omitting closing tags OK only in simpler hand-coded cases with a lot of repetition, like tables, lists, definition lists (often forgotten), and obviously void elements.
I'd also wish people would stop calling every element-specific behavior HTML parsers do "liberal and tag-soup"-like. Yes WHATWG HTML does define error recovery rules, and HTML had introduced historic blunders to accomodate inline CSS and inline JS, but almost always what's being complained about are just SGML empty elements (aka HTML void elements) or tag omission (as described above) by folks not doing their homework.
[1]: https://sgmljs.sgml.net/docs/html5.html#tag-omission (see also XML Prague 2017 proceedings pp. 101ff)
https://nvd.nist.gov/vuln/detail/CVE-2020-26870
https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not...
https://bughunters.google.com/blog/5038742869770240/escaping...
None of those problems exist in XHTML.
I learned HTML quite late, when HTML 5 was already all the rage, and I never understood why the more strict rules of XML for HTML never took off. They seem so much saner than whatever soup of special rules and exceptions we currently have. HTML 5 was an opportunity to make a clear cut between legacy HTML and the future of HTML. Even though I don't have to, I strive to adhere to the stricter rules of closing all tags, closing self-closing tags and only using lower-case tag names.
Original SGML was actually closer to markdown. It had various options to shorten and simplify the syntax, making it easy to write and edit by hand, while still having an unambiguous structure.
The verbose and explicit structure of xhtml makes it easier to process by tools, but more tedious for humans.
It’s kind of a huge deal that I can give a Markdown file of plain text content to somebody non-technical and they aren’t overwhelmed by it in raw form.
HTML fails that same test.
Especially for casual users of HTML.
“Always close your tags” is a simpler rule (and fewer rules, depending how you count) than “Close your tags, except possibly in situations A, B, C…”.
And markdown tables are harder to write than HTML tables. However, they are generally easier to read. Unless multi line cell.
Internet Explorer failing to support XHTML at all (which also forced everyone to serve XHTML with the HTML media type and avoid incompatible syntaxes like self-closing <script />), Firefox at first failing to support progressive rendering of XHTML, a dearth of tooling to emit well-formed XHTML (remember, those were the days of PHP emitting markup by string concatenation) and the resulting fear of pages entirely failing to render (the so-called Yellow Screen of Death), and a side helping of the WHATWG cartel^W organization declaring XHTML "obsolete". It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax.
I think most of those are actually no longer relevant, so I still kind of hope that XHTML could have a resurgence, and that the tag-soup syntax could be finally discarded. It's long overdue.
Meanwhile, in any other formal language (including JS and CSS!), the standard assumption is that syntax errors are fatal, the responsibility for fixing lies with the page author, but also that fixing those errors is not a difficult problem.
Why is this a problem for HTML - and only HTML?
Your premise is not correct because you're not aware that other data formats also have parsers that accept malformed content. Examples:
- pdf files: many files with errors can be read by Adobe Acrobat. And code PDF libraries for developers often replicate this behavior so they too can also open the same invalid pdf files.
- zip files. 7-Zip and WinRAR can open some malformed zip files that don't follow the specification. E.g. 7-Zip has extra defensive code that looks for a bad 2-byte sequence that shouldn't be there and skips over it.
- csv files. MS Excel can read some malformed csv files.
- SMTP email headers: Mozilla Thunderbird, MS Outlook, etc can parse fields that don't exactly comply with RFC 822 -- make some guesses -- and then successfully display the email content to the user
The common theme to the above, including HTML... the Raw Content is more important than a perfectly standards-compliant file format. That's why parsers across various domains make best efforts to load the file even when it's not 100% free of syntax errors.
The web owes its success to having low barriers to entry and very quickly became a mixture of pages hand coded by people who weren't programmers, content produced by CMS systems which included stuff the content author didn't directly control and weren't necessarily reliable at putting tags into the right place, and third party widgets activated by pasting in whatever code the third party had given you. And browsers became really good at attempting to rendering erroneous and ambiguous markup (and for that matter were usually out of date or plain bad at rigidly implementing standards)
There was a movement to serve XHTML as XML via the application/xhtml+xml MIME type never took off because browsers didn't do anything with it except loading a user-hostile error page if a closing tag was missed (or refusing to load it at all in the case of IE6 and older browsers), and if you wanted to do clever transformation of your source data, there were ways to achieve that other than formatting the markup sent to the browser as a subset of XML
We could be more strict for new content, but why bother if you have to include the legacy parser anyway. And the HTML5 algorithm brings us most of the benefits (deterministic parsing) of a stricter syntax while still allowing the looseness.
Try going to any 1998 web page in a modern browser... It's generally so broken so as to be unusable.
As well as every page telling me to install flash, most links are dead, most scripts don't run properly (vbscript!?), tls versions now incompatible, etc.
We shouldn't put much effort into backwards compatibility if it doesn't work in practice. The best bet to open a 1998 web page is to install IE6 in a VM, and everything works wonderfully.
Netscape started this. NCSA was in favor of XML style rules over SGML, but Netscape embraced SGML leniency fully and several tools of that era generated web pages that only rendered properly in Netscape. So people voted with their feet and went to the panderers. If I had a dollar for every time someone told me, “well it works in Netscape” I’d be retired by now.
Well, this is not entirely true: XML namespaces enabled attaching arbitrary data to XHTML elements in a much more elegant, orthogonal way than the half-assed solution HTML5 ended up with (the data-* attribute set), and embedding other XML applications like XForms, SVG and MathML (though I am not sure how widely supported this was at the time; some of this was backported into HTML5 anyway, in a way that later led to CVEs). But this is rather niche.
But.
The future of HTML will forever contain content that was first handtyped in Notepad++ in 2001 or created in Wordpress in 2008. It's the right move for the browser to stay forgiving, even if you have rules in your personal styleguide.
Besides, at this point technologies like tree-sitter make editor integration a moot point: once tree-sitter knows how to parse it, the editor does too.
A p or li tag, at least when used and nested properly, logically ends where either the next one begins or the enclosing block ends. Closing li also creates the opportunity for nonsensical content inside of a list but not in any list item. Of course all of these corner cases are now well specified because people did close their tags sometimes.
While this is true I’ve never liked it.
Implies a closing </p> in the middle. But Does not. Obviously with the knowledge of the difference between what span and p represent I understand why but in terms of pure markup it’s always left a bad taste in my mouth. I’ll always close tags whenever relevant even if it’s not necessary.In practice, modern HTML splits the difference with rigorous and well defined but not necessarily intuitive semantics.
So we'll add another syntax for browsers to handle.
https://xkcd.com/927/
> On void elements, [the trailing slash] does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
It was mainly added to HTML5 to make it easier to convert XHTML pages to HTML5. IMO using the trailing slash in new pages is a mistake. It makes it appear as though the slash is what closes the element when in reality it does nothing and the element is self-closing because it's part of a hardcoded set of void elements. See here for more information: https://github.com/validator/validator/wiki/Markup-%C2%BB-Vo...
The third way of a bare tag is where the confusion comes from.
Now, we can discuss whether we should optimize for the unfamiliar reader, and whether the illusion of actual meaning the trailing slash in HTML5 can be harmful.
I would note that exactly like trailing slashes, indentation doesn't mean anything for the parser in C-like languages and can be written misleadingly, yet we do systematically use it, even when no unfamiliar reader is expected.
At this point, writing a slash or not and closing all the tags is a coding style discussion.
Now, maybe someone writing almost-XHTML (closing all tags, putting trailing slashes, quoting all the attributes) should go all the way and write actual XHTML with the actual XHTML content type and benefit from the strict parser catching potential errors that can backfire and that nobody would have noticed with the HTML 5 parser.
Because browsers close some tags automatically. And if your closing tag is wrong, it'll generate empty element instead of being ignored. Without even emitting warning in developer console. So by closing tags you're risking introducing very subtle DOM bugs.
If you want to close tags, make sure that your building or testing pipeline ensures strict validation of produced HTML.
Netscape Navigator did, in fact, reject invalid HTML. Then along came Internet Explorer and chose “render invalid HTML dwim” as a strategy. People, my young naive self included, moaned about NN being too strict. NN eventually switched to the tag soup approach. XHTML 1.0 arrived in 2000, attempting to reform HTML by recasting it as an XML application. The idea was to impose XML’s strict parsing rules: well-formed documents only, close all your tags, lowercase element names, quote all attributes, and if the document is malformed, the parser must stop and display an error rather than guess. XHTML was abandoned in 2009. When HTML5 was being drafted in 2004-onwards, the WHATWG actually had to formally specify how browsers should handle malformed markup, essentially codifying IE’s error-recovery heuristics as the standard.
Leaving out closing tags is possible when the parsing is unambigous. E.g <p>foo<p>bar is unambiguous becuse p elements does not nest, so they close automatically by the next p.
The question about invalid HTML is a sepearate issue. E.g you can’t nest a p inside an i according to the spec, so how does a browser render that? Or lexical error like illegal characters in a non-quoted attribute value.
This is where it gets tricky. Render anyway, skip the invalid html, or stop rendering with an error message? HTML did not specify what to do with invalid input, so either is legal. Browsers choose to go with the “render anyway” approach, but this lead to different outputs in different browsers, since it wasn’t agreed upon how to render invald html.
The difference between Netscape and IE was that Netscape in more cases would skip rendering invalid HTML, where IE would always render the content.
The oldest public HTML documentation there is, from 1991, demonstrates that <li>, <dt>, and <dd> tags don't need to be closed! And the oldest HTML DTD, from 1992, explicitly specifies that these, as well as <p>, don't need closing. Remember, HTML is derived from SGML, not XML; and SGML, unlike XML, allows for the possibility of tags with optional close. The attempt to make HTML more XML-like didn't come until later.
This is clear in Tim Berners-Lee's seminal, pre-Netscape "HTML Tags" document [0], through HTML 4 [4] and (as you point out) through the current living standard [5].
[0] https://www.w3.org/History/19921103-hypertext/hypertext/WWW/...
[4] https://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1
[5] https://html.spec.whatwg.org/multipage/syntax.html#optional-...
Because table layout was common, a missing </table> was a common error that resulted in a blank page in NN. That was a completely unintentional bug.
Optional closing tags were inherited from SGML, and were always part of HTML. They're not even an error.
Around 2000, I was meeting with Tim Berners-Lee, and I mentioned I'd been writing a bunch of Web utility code. He wanted to see, so I handed him some printed API docs I had with me. (He talked and read fast.)
Then I realized he was reading the editorializing in my permissive parser docs, about how browser vendors should've put a big error/warning message on the window for invalid HTML.
Which suddenly felt presumptuous of me, to be having opinions about Web standards, right in front of Tim Berners-Lee at the time.
(My thinking with the prominent warning message that every visitor would see, in mid/late-'90s, was that it would've been compelling social pressure at the time. It would imply that this gold rush dotcom or aspiring developer wasn't good at Web. Everyone was getting money in the belief that they knew anything at all about Web, with little way to evaluate how much they knew.)
edit: Indeed, it creates three: the </p> seems to create an empty paragraph tag. Not the first time I've been surprised by tag soup rules.
Why?
> You may think that's invalid HTML, but browser will parse it and won't indicate any kind of error.
It isn’t an opinion, it literally is invalid HTML.
What you’re responding to is an assumption that I was suggesting browsers couldn’t render that. Which isn’t what I claimed at all. I know full well that browsers will gracefully handle incorrect HTML, but that doesn’t mean that the source is magically compliant with the HTML specification.
I don't know why. Try it out. That's the way browsers are coded.
> It isn’t an opinion, it literally is invalid HTML.
It matters not. You're writing HTML for browser to consume, not for validator to accept. And most of webpages are invalid HTML. This very HN page contains 412 errors and warnings according to W3C validator, so the whole point of HTML validness is moot.
I’m not saying you’re wrong, but I’d need more than that to be convinced. Sorry.
> It matters not. You're writing HTML for browser to consume, not for validator to accept.
It matters because you’re arguing a strawman argument.
We weren’t discussing what a browser can render. We were discussing the source code.
So your comment wasn’t a rebuttal of mine. It was a related tangent or addition.
So basically my point is:
1. You can avoid closing some tags, letting browser to close tags for you. It won't do any harm.
2. You can choose to explicitly close all tags. It won't do anything for valid HTML, but it'll introduce subtle and hard to find DOM bugs by adding empty elements.
So you're trying to improve HTML source readability by risking to introduce subtle bugs.
If you want to do that, I'd recommend to implement HTML validation for build or test pipeline at least.
Another alternative is to use HTML comments to close tags, as this closing tag is supposed to be documentation-only and won't be used by browser in a proper code.
You posted a terse comment with some HTML. I responded specifically about that comment and HTML. And you’re now elaborating on things as a rebuttal to my comment despite the fact that wasn’t the original scope of my comment.
Another example of that is how you’ve quoted my reply to the 2 vs 3 elements, and then answered a completely different question (one I didn’t even ask).
I don’t think you’re being intentionally obtuse but it’s still a very disingenuous way to handle a discussion.
It doesn't make the code valid according to the specifications.
Though if a linter is formatting the whole codebase on its own in an homogeneous way, and someone else will deal with the added parsing complexity, that might feel okayish also to me.
Generally speaking, the less clutter the better. A bit like with a js codebase which is semicolon free where possible.
For pleasant experience of read and write, html in a simple text editor is very low quality. Pug for example is bringing far less clutter, though mandatory space indentation could be avoided with some alternative syntactic choices.
So I think your argument here is tough to take at face value. It feels a lot more like you’re arguing personal preference as fact.
There being nesting is just implied by the closing tags and indentation. But it is not actually there. I think this is the point of the example: Adding the closing tags just confuses the reader, by implying nesting that is not actually there, and even introduces a third empty paragraph. It might be better left out entirely.
The syntax is invalid, but that's because the final </p> has no opening <p> that it can close.
I think this is the point of the example, afaiui: The closing tags don’t clarify anything, quite the contrary, actually. They serve only to confuse the reader.
That said, your linter is going to drive you crazy if you don't close tags, no?
You should close your tags. It’s good hygiene. It helps IDEs help you. But. Trust me, you do not want the browser enforcing it at runtime, lest your idea of fun is end users getting helpful error messages like an otherwise blank screen saying “Invalid syntax”.
For fun, imagine that various browsers are not 100.00% compatible (“Inconceivable!”), so that it wasn’t possible to write HTML that every browser agreed was completely valid. Now it’s guaranteed that some of your users will get the error page, even when you’re sure your page is valid.
Conceptually, XHTML and its analogs are better. In practice, they’re much, much worse.
Payload size is a moot point given gzip.
But honestly no answer to "what does the browser do with this sort of thing" fits into an HN comment anymore. I'm glad there's a standard, but there's a better branch of the multiverse where the specification of what to do with bad HTML was written from the beginning and is much, much simpler.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Correction: there was also the issue of Ä and Ö. Those were &AUML; and &OUML; I think.
https://timonoko.github.io/alaska/index.htm
I hand write my HTML sometimes, and in those cases it’s often very basic documents consisting of maybe an outer container div, a header and a nav with a ul of li for the navigation items and then an inner container div and maybe an article element, and then the contents are mostly p and figure elements and various level headings.
In this case, there is no mental overhead of omitting closing li and closing p at the end of the line, and I omit them because I am allowed to and it’s still readable and fine.
(This is especially relevant with "void" tags. E.g. if someone wrote "<img> hello </img>" then the "hello" is not contained in the tag. You could use the self closing syntax to make this more obvious -- Edit: That's bad advice, see below.)
e.g. how do you think a browser will interpret this markup?
A lot of people think it ends up like this (especially because JSX works this way): but it's actually equal to this:Laziness doesn't play a role. This isn't XML where you need to repeat yourself over and over again or abusing a bug in the rendering logic; it's following the definitions markdown language you're writing content in.
If you're not too familiar with the HTML language then it's always a safe bet to close your tags, of course.
If you don't close your <p> and <li> tags, you risk accidentally having content in the wrong place.
It's something to avoid because it can have bad consequences, not because it (somehow?) makes you a bad person.
The problem is when you have long cells that you’d normally word wrap inside the cell, everything else ends up misaligned in your markup language. Or when you need to add styling to text in a cell, suddenly it’s unreadable again. Or when there’s more than a small few number of columns thus causing each row to word wrap inside your IDE, etc
I think it makes far more sense to just acknowledge that tables are going to ugly, compose them elsewhere, and then export them to your markup language following that language’s specification strictly.
In fact, most web browsers now automatically insert these closing tags for the user.
This feature has been around for many years now.
However, I have found that many organizations still require that the closing tags be included explicitly.
I am curious how other organizations determine when to use the "the spec allows it" as a reason to not include the closing tags.
What point do developers cross from merely allowing this to being considered a technical debt?
Have you ever utilized the feature of the specification that caused you a problem later?
Just because it worked on the one browser you tested it on, doesn't mean it's always worked that way, or that it will always work that way in the future...
Every browser treats html/etc differently... I've run into css issues before on Chrome for android, because I was writing using Chrome for desktop as a reference.
You'd think they should be the same because they come from the same heritage, but no...
All browsers have worked this way for decades. It’s standard HTML that has been in widespread use since the beginning of the web. The further back you go, the more normal it was to write HTML in this style. You can see in this specification from 1992 that <p> and <li> don’t have closing tags at all:
https://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
Maybe there were obscure browsers that had bugs relating to this back in the mid 90s, but I don’t recall any from the late 90s onwards. Can you name a browser released this millennium that doesn’t understand optional closing tags?
Literally saving four bytes.
(But it might be better if you make a habit of doing so.)
Or am I pointing out that closing tags is a human social issue, with aspects ranging from practical & reasonable, to ridiculous & widely exploited?
> XHTML, being based on XML as opposed to SGML, is notorious for being author-unfriendly due to its strictness
This strictness is a moot point. Most editors will autocomplete the closing tag for you, so it's hardly "unfriendly". Besides, if anything, closing tags are reader-friendly (which includes the author), since they make it clear when an element ends. In languages that don't have this, authors often add a comment like `// end of ...` to clarify this. The article author even acknowledges this in some of their examples ("explicit end tags added for clarity").
But there were other potential benefits of XHTML that never came to pass. A strict markup language would make documents easier to parse, and we wouldn't have ended up with the insanity of parsing modern HTML, which became standardized. This, in turn, would have made it easier to expand the language, and integrate different processors into the pipeline. Technologies like XSLT would have been adopted and improved, and perhaps we would have already had proper HTML modules, instead of the half-baked Web Components we have today. All because browser authors were reluctant to force website authors to fix their broken markup. It was a terrible tradeoff, if you ask me.
So, sure, feel free to not close HTML tags if you prefer not to, and to "educate" everyone that they shouldn't either. Just keep it away from any codebases I maintain, thank you very much.
To be fair, I don't mind not closing empty elements, such as `<img>` or `<br>`. But not closing `<p>` or `<div>` is hostile behavior, for no actual gain.
This non-closing talisman means that <div/> or <script/> are not closed, and will mess up nesting of elements.
> if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/)
If you're going to be pedantic, at least be correct about it.
[1]: https://html.spec.whatwg.org/multipage/syntax.html#start-tag...
> On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
(The void elements are listed here: https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme... )
If that's a comment you get, write better code. It does not matter to me whether closing p-tags is mandatory or optional. If you don't do it, I don't want you working on the same code base as me.
This kind of knowledge makes for fun blog posts, but if people direct these kind of comments to me. You're obviously using your knowledge to just patronize and lecture people.
This may have been relevant 9 years ago, but today, just pick and auto-formatter like prettierjs and have it close these tags for you.
1. The autoclose syntax does not exist in HTML5, and a trailing slash after a tag is always ignored. It's therefore recommended to avoid this syntax. I.e write <br> instead of <br />. For details and a list of void elements, see https://developer.mozilla.org/en-US/docs/Glossary/Void_eleme...
2. It's not mandatory to close tags when the parser can guess where they end. E.g. a paragraph cannot contain any line-block, so <p>a<div>b</div> is the same as <p>a</p><div>b</div>. It depends on the context, but putting an explicit end tag is usually less error-prone.
Some rules of thumb, perhaps:
— Do not omit if it is a template and another piece of HTML is included in or after this tag. (The key fact, as always, is that we all make errors sometimes—and omitting a closing tag can make an otherwise small markup error turn your tree into an unrecognisable mess.)
— Remember, the goal in the first place is readability and improved SNR. Use it only if you already respect legibility in other ways, especially the lower-hanging fruit like consistent use of indentation.
— Do not omit if takes more than a split-second to get it. (Going off the HTML spec, as an example, you could have <a> and <p> as siblings in one container, and in that case if you don’t close some <p> it may be non-obvious if an <a> is phrasing or flow content.)
The last thing you want is to require the reader of your code to be more of an HTML parser than they already have to be.
For me personally this makes omitting closing tags OK only in simpler hand-coded cases with a lot of repetition, like tables, lists, definition lists (often forgotten), and obviously void elements.