8 ms·
You are not required to close your <p>, <li>, <img>, or <br> tags in HTML
- delaminator 9mo agoGo back a bit further for why. 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.
- Sniffnoy 9mo agoThe 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.
- cvcount 9mo agoI 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.
- bazoom42 9mo agoBut 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.
- ezequiel-garzon 9mo agoOptinal 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]. [0] https://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html https://www.w3.org/History/19921103-hypertext/hypertext/WWW/... [4] https://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1 https://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1 [5] https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
- pornel 9mo agoNN did not reject invalid HTML. It could not incrementally render tables, while IE could. That's all. 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.
- neilv 9mo agoI 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.)
- hinkley 9mo agoFormer 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.
- osxman 9mo agoIt would be nice though, to close 'm ... Makes it more readable and less prone to mistakes.
- bmacho 9mo agoArticle 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. <table> <tr> <td> A1 <td> B1 <td> C1 <tr> <td> A2 <td> B2 <td> C2 <tr> <td> A3 <td> B3 <td> C3 </table> 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.
- hnlmorg 9mo agoI 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.
- sieabahlpark 9mo ago[dead]
- deleted 9mo ago[deleted]
- ZiiS 9mo agoYou are also not required to indent code (in most languages); please do if you want me to read it though.
- dashzebra 9mo agoYou can also indent with spaces and tabs at the same time, who's judging?
- vbezhenar 9mo agoClosing optional HTML tags just adds more ambiguity. How many HTMLParagraphElements here, what do you think? <p> text1 <p> text2 </p> </p>
- nh43215rgb 9mo agoPlease just close them though.
- runarberg 9mo agoNeeds a (2017) in the title. 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.
- imiric 9mo agoThe 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.
- recursive 9mo agoImg and br are not allowed to be closed.
- swiftcoder 9mo agoWorse, due to the aforementioned permissive error handling in HTML parsers, a closing </br> tag will end up inserting a second line break
- imiric 9mo agoWrong.[1] > 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-tags https://html.spec.whatwg.org/multipage/syntax.html#start-tag...
- themafia 9mo agoYea but it feels gross when I don't.
- patrickmay 9mo agoYou just confessed to having taste.
- deleted 9mo ago[deleted]
- seydor 9mo agoYeah 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
- QuantumNomad_ 9mo agoIt 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.
- renegade-otter 9mo agoJust because you can, doesn't mean you should.
- bell-cot 9mo agoAlso true: You are not required to bathe IRL. (But it might be better if you make a habit of doing so.)
- card_zero 9mo agoThis is ridiculous. You're genuinely applying social pressure to close tags. I remember when this began, drove me nuts.
- bell-cot 9mo agoAn anonymous account on HN is applying social pressure? Or am I pointing out that closing tags is a human social issue, with aspects ranging from practical & reasonable, to ridiculous & widely exploited?
- gregoriol 9mo agoI 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
- QuantumNomad_ 9mo agoTo 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: <nav id=main-nav> <ul> <li><a href="/">Home</a> <li><a href="/hamburgers/">Hamburgers</a> <li><a href="/sausages/">Sausages</a> </ul> </nav>
- danaris 9mo agoThe personal judgement isn't really helpful here? 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.
- jeroenhd 9mo ago<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.
- weinzierl 9mo agoIf I remember correctly Google's front page did this in the early days to save a few bytes.
- reddalo 9mo agoYou're technically right, it seems like they had one single unclosed <p> right at the end of the page, for the copyright footer: https://web.archive.org/web/20010510221642/http://www.google.com/ https://web.archive.org/web/20010510221642/http://www.google... Literally saving four bytes.
- timonoko 9mo ago<p> was the only thing I knew when I constructed Finland's First Ever WEB-page in 1992. Correction: there was also the issue of Ä and Ö. Those were &AUML; and &OUML; I think. https://timonoko.github.io/alaska/index.htm https://timonoko.github.io/alaska/index.htm
- timonoko 9mo agoOn 640x480 VGA-display this page looks quite alright.
- 7bit 9mo ago> "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.
- deleted 9mo ago[deleted]
- nine_k 9mo agoYou don't need to close these tags. But if you value your sanity more than saving a few bytes, you as well may close them, it's not an error.
- MORPHOICES 9mo ago[flagged]
- nubinetwork 9mo ago> 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...
- JimDabell 9mo ago> 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: https://info.cern.ch/hypertext/WWW/MarkUp/Tags.html 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?
- HiPhish 9mo agoSerious 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.
- vbezhenar 9mo ago> why would you ever want to not close tags? 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.
- pwdisswordfishy 9mo ago> 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.
- idoubtit 9mo agoThis 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_element 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.
- vbezhenar 9mo agoPutting 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.
- strogonoff 9mo agoThere 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.
- blauditore 9mo agoI 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.
- layer8 9mo agoIn the context of javadoc, you can think of <p> as a paragraph break, just like <br> is a line break.
- chaz6 9mo agoIf I enter the following:- <p><p></p> Should the second <p> be nested or not?
- bazoom42 9mo agoNo. P elements does not nest, so this is parsed as: <p></p><p></p>
- 6510 9mo agoI always thought this was funny. Practical but not the usual open/close order. aaaaa<b>aaaa<i>aaaaa</b>aaaa</i>aaaaa I just tried this! <table> <tr><td>aaaaa<td>bbb <tr><td>ccccccccccc<td>dddddddddd <tr><td>eeeeeeeeeeeeeeeee </table> Which works and is much cleaner than the usual table tag soup. It makes sense as on their own <td> and <tr> tags have no meaning.
- xg15 9mo agoWhether 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.)
- oneeyedpigeon 9mo agoI absolutely agree. Also, if you want to parse HTML as XML, it's a lot more reliable having it in a known 'good' format to begin with.
- mathgeek 9mo agoThis is where I always end up as well. Just because you can do something doesn’t mean you should or shouldn’t.
- jakelazaroff 9mo agoThe 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): <div></div> <img> but it's actually equal to this: <div> <img> </div>
- xg15 9mo agoAh, that's true. I think the WHATWG discouraged the syntax, so this might be why.
- ricardobeat 9mo agoThis is really easy to detect though, unlike arbitrary rules on what belongs on the inside of an unclosed tag.
- didip 9mo agoEarly Google did not close their tags, I think it was for the sake of payload size? That said, your linter is going to drive you crazy if you don't close tags, no?
- robust-cactus 9mo agoHow 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? Payload size is a moot point given gzip.
- jakelazaroff 9mo agoYou cannot nest <li>. An <li> may only be a child of <ol>, <ul> or <menu>. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/li https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- jerf 9mo agoPerhaps 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.
- dangoodmanUT 9mo agoConsidering I can’t scroll down on ios safari, maybe you should…
- jeroenhd 9mo agoWorks 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?
- tannhaeuser 9mo agoGuess 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. [1]: https://sgmljs.sgml.net/docs/html5.html#tag-omission https://sgmljs.sgml.net/docs/html5.html#tag-omission (see also XML Prague 2017 proceedings pp. 101ff)
- pwdisswordfishy 9mo agoThis is what I complain about: https://nvd.nist.gov/vuln/detail/CVE-2020-26870 https://nvd.nist.gov/vuln/detail/CVE-2020-26870 https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not-to-break-a-site/ https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... https://bughunters.google.com/blog/5038742869770240/escaping-and-in-attributes-how-it-helps-protect-against-mutation-xss https://bughunters.google.com/blog/5038742869770240/escaping... None of those problems exist in XHTML.
- tannhaeuser 9mo agoI guess you're replying to my comment because you were triggered by my last sentence. I wasn't criticizing you specifically, but yeah, in another comment you're writing > It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax. which unfortunately reaks of exactly the kind of roundabout HTML criticism that is not so helpful IMO. We have to face the possibility that most HTML documents have already been written at this point, at least if you value text by humans. The CVEs you're referencing are due to said historic blunders allowing inline JS or otherwise tunneling foreign syntax in markup constructs (mutation XSSs are only triggered by serialising and reparsing HTML as part of bogus sanitizer libs anyway). If you look at past comments of mine, you'll notice I'm staunchly criticizing inline JS and CSS (should always be placed in external "resources") and go as far as saying CSS or other ad-hoc item-value syntax should not even exist when attributes already serve this purpose. The remaining CVE is made possible by Hickson's overly liberal rules for what's allowed or needs escaping in attributes vs SGML's much stricter rules.
- BigTTYGothGF 9mo agoMy 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.
- avidphantasm 9mo ago…but civilized people do close them.
- thrill 9mo agoYou are if I’m doing your code review.
- s_ting765 9mo agoSame with <svg> but Firefox's XML parser will not greenlight you.
- kstrauser 9mo agoI 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.
- Robdel12 9mo agoPlease do, though :)
- EmilStenstrom 9mo agoTo see the actual errors, just paste your HTML here and see: https://emilstenstrom.github.io/justhtml/playground/ https://emilstenstrom.github.io/justhtml/playground/ - any parsing errors show up below the input box. Some tags do require ending tags, others do not. Personally I find it hard to remember which ones, so I just close things out of caution. That way you’re always spec-correct.
- 1vuio0pswjnm7 9mo agoI use this daily with local HTML files, specifically not closing <li> tags For example, I generate numbered lists of URLs something like <li><a href=http://example.com>http://example.com</a> This is for text-only browser If I am viewing in graphical browser I wrap the lists in <pre> tags I don't think I've ever closed <br> tags
- thedelanyo 9mo agoI cannot fathom writing <p> without</p> to wrap a text.
- downsplat 9mo agoYou do you in terms of taste, but the article explains very clearly that there's nothing wrong about not closing them, as they are reliably auto-closed by a well-defined standard.
- Sohcahtoa82 9mo agoI feel like this is in the same vein as semicolons being "optional" in JavaScript. It's wrong, but the engines know how to make it work anyways.
- lasgawe 9mo agoI never knew that. I don't know why. I've never seen this mentioned in a book, tutorial, or anything.
- dhosek 9mo agoThe “loose” standards of HTML led to some really awful things happening in the early web. I remember seeing, e.g., <large><li></large> item text to get a bigger bullet on a list item which worked fine in Netscape but broke other browsers (and since I was on OS/2 at the time, it was an issue for me). Really, in 2025 people should just write XHTML and better yet, shouldn’t be generating HTML by hand at all except for borderline cases not handled by their tools.
- webstrand 9mo agoUnfortunately XHTML5 doesn't exist and if you try to force the issue, you have to re-declare all of the non-numeric HTML entities in your own DTD (I abandoned the idea here). I'd love to use XHTML, its just not viable anymore. As for generating all HTML, that's simply not possible given the current state (of open-source at least) WYSIWYG HTML editors.
- lcnmrn 9mo agoI wish HTML 6 will actually be XHTML 6.
- dhosek 9mo agoI stopped using entities once we had UTF-8. I suppose there’s a case for the occasional < > but beyond that, I have no problem typing “‘—’” or üçě when I need to.
- pwdisswordfishy 9mo ago> Unfortunately XHTML5 doesn't exist This is a mirage, apparently: https://html.spec.whatwg.org/multipage/xhtml.html https://html.spec.whatwg.org/multipage/xhtml.html
- webstrand 9mo agoThat's not HTML5 as far as I can tell. If you want both HTML5 and XML validation, you have to write your own DTD.
- senfiaj 9mo agoMaybe you are not required to close, browsers are ridiculously tolerant to html mistakes. But do you think it would be easy to maintain that HTML file and not accidentally include something in that unclosed tag? I often format with indentation in order to work with the file comfortably. Also it annoys me when people are still closing tags with '/>'.
- jihadjihad 9mo agoI didn’t have any rigorous training or anything, but my understanding since learning HTML way back in high school was, like the author mentions in TFA, tags like <br> and <p> can simply be used “as-is” as markup and don’t need the concept of being closed. I write virtually zero HTML anymore, but the one time this sort of thing comes up is in writing PR descriptions in GitHub using Markdown. Sometimes I want to add a <br> or two for space. I guess I’ve never stopped to notice that I never close those tags after adding them, or wondered why in my head it makes sense not to!
- BiraIgnacio 9mo agoI'd think handling these cases would be nightmare for html parsers.
- hk1337 9mo agoYou’re not really required to with anything in HTML or to even use HTML, you could do everything plain text if you wanted
- notepad0x90 9mo ago<p>some sentence here <img src="img.jpeg"/> <p> some other sentence. In that example, the image could be part of the first paragraph, as it is there, or if i moved the second <p> before the <img> it would be part of the second. but if I want neither, do I not have to close the first paragraph? Here is a demo of what i mean on this random html paste site: https://htmlbin.online/closetagdemo https://htmlbin.online/closetagdemo I don't know what "not required" means, but it makes a difference with <p> at least in my opinion. I think the author meant that if the succeeding element is of the same type, you don't need to close the previous one. But even then, this is not a good feature, browsers aren't the only things processing html content, any number of tooling, or even human readers can get confused.
- alexshendi 9mo agoBut I want to! :)
- mary-ext 9mo agoSolid.js and Vue uses these sorts of tricks to shave the amount of bytes from the HTML templates they generate https://github.com/vuejs/core/commit/30dbdc101a48d747b56bcddc4da4d667c273e1b2 https://github.com/vuejs/core/commit/30dbdc101a48d747b56bcdd...
- OptionOfT 9mo agoI find it very sad that XHTML didn't win over HTML5. More strictness I think would've helped remove a lot of ambiguity.
- evadne 9mo agoThis is like saying you do not have to use semicolons in JavaScript