HTML will let us do almost anything, right or wrong, and will make an effort to render it. It doesn’t care about valid markup. As shown above, that markup is invalid so why pursue it?
What purpose would a button inside a button have? No, I’m not saying we can’t or shouldn’t do it, but we would need a good reason and would be hoping that all platforms will support it.
Bottom line, learn how to write valid markup that makes sense to the reader.
Alright, thank you for letting me to know more on this!
The browser won’t know where the HTML element ends and will render an unexpected result.
On the topic of “closing tags”, on the cases of elements that don’t need closing tags like img, what’s the preferred method? Close it with “>” or “/>”? I ask this because I’ve seen both cases being used, and it got me curious which one is the most “correct” to use.
This is a good question, only made more difficult to answer if the learner is not familiar with HTML 4.01 or XHTML 1.0 or XHTML 1.1. Those are all three very different languages when we dial into the individual namespaces.
Briefly, in HTML 4 (for short) this was an image element:
<img src="#" alt="">
In XHTML due to its compliance with XML specifications which does not allow ‘void elements’, the compromise made in the recommendations was this,
<img src="#" alt=""/>
as opposed to,
<img src="#" alt=""></img>
which developers were definitely not used to typing.
The recommendation was accepted but then IE5.2 (?) for Mac was crapping out on the syntax. The open source world discovered the hack to fix this, so it was adopted as the recommendation:
<img src="#" alt="" />
And away we went into the world of XHTML development. Most of my past sites are marked up in this language (XHTML 1.0). By the time HTML5 came around I was nearing retirement. I never served XHTML 1.1 which was a much more technical version of 1.0 used largely at the ultra professional level with complex, XML rich environments. We don’t need to go there.
HTML5 recommenders came up with a compromise with respect to HTML 4 and XHTML: Make it comply with both. When served as text/html it follows the recommendation for HTML 4 (with some revision) and when served as text/xml it follows recommendations for XHTML (sans Mac hacks).
So in HTML5,
<img src="#" alt="">
<img src="#" alt=""/>
<img src="#" alt="" />
are all valid. Served as ‘text/html’ the slashes and space-slashes are ignored. Served as ‘text/xml’ the slash is needed, but the space is not, though it is allowed and ignored. If the page is served with no CONTENT-TYPE metadata, it defaults to ‘text/html’ MIME type. HTML5 has a good set of de facto characterizations which was a boon for developers, to be sure. We can leave a lot of stuff out that used to be required, including ‘type’ attributes on ‘.css’ and ‘,js’ requests. among other things.
Bottom line, for our purposes we don’t need the slash. You won’t risk being called lazy if you leave it out and form the habit of NOT using it. For the most part we are writing HTML 4 and so long as our markup is well formed, we are on track to a valid page.
Confusing? Let me know so we can dig a little deeper.
That’s was a such an awesome reply! I doubt I’d ever find this answer if I googled. Thank you so much for the clarification!! 
I really appreciate the idea.
This was very helpful. Thank You
Yes, to let the browser know the coding language, it requires to provide opening and close tags with the attribute. so that browser can pick which attribute it is and where it needs to apply. While creating a Tracking button for UMAC Balikbayan Box Tracking i tried to go without closing tag. After so many tries and research i got to know the closing tag is compulsory.
If you don’t add a closing tag for an HTML element, the browser will try to interpret the HTML and render the page as best as it can. However, it may lead to unexpected or incorrect rendering, especially if the missing closing tag affects the structure of the page. In some cases, the browser may automatically add a closing tag to correct the structure, but this is not guaranteed across all browsers and situations. Always include closing tags to ensure proper rendering and maintain code clarity.
Cannot totally agree with that. The browser does not ‘correct the structure’. It is the specification that states the permissibility of tag omission
Tag omission
Anaelement must have both a start tag and an end tag.
Tag omission
An li element must have a start tag.
Anlielement’s end tag may be omitted if thelielement is immediately followed by anotherlielement or if there is no more content in the parent element.
Tag omission
A p element must have a start tag.
A p element’s end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hr, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is not an a element.
Read the specs and learn which situations permit tag omission rather than speculate or single out browser support. Today’s browsers are pretty much 100% W3C compliant in their application of the HTML5 recommendations.
Awesome, thank you so much for the clarification, it’s my second day here, so much to learn. 
You’re welcome. Second day here; hmmm. Seems ill placed to be answering the headline question of an FAQ topic, years after the fact. We’ll leave you to decide. A good answer will be recognized, as will be a poor one. We have members who will fact check and reply. Be a helpful member, not a nuisance is what we’re basically saying. Answer current questions, not dead ones, especially those in FAQ. Work on the learning aspect and share that outcome with other learners, as needs present themselves.
Back when it was just HTML 4, without closing tags would result in an error, but now HTML 5 doesn’t need it but it’s better practice to use them because it tells you when it ends. Can’t wait for HTML 6, I’ve read that it is supposed to have more semantic meaning behind it
Or more precisely, a validation error, not a fatal error, per se. HTML has always been tolerant of invalid markup, and just did its best to render whatever we give the browser. All HTML5 did was fill in some gaps and call it “optional”.
Validated markup still counts as one of the more than 200 metrics used by search engines, where SEO is concerned. Apart from that it’s not like the browser cared one way or the other.
Our responsibility as developers is to know the recommendations that the browser knows, and follow them on the faith that the browser will, too, as promised by the vendors.
As for semantic improvements, all that will change is the names on the tags. From the very outset, HTML was meant to be structured on the basis of an outline, which lends itself in a huge way to semantics. It was a big concern, even in the 80s and 90s. Nothing has really changed other than the maturity of the language.
I somehow forgot to keep / in closing tag and it all became bold