I’m surprised to see the highlights don’t include another common detail of the parsing algorithm that often trips people up: table rows and cells (tr/th/td) must be in one of thead/tbody/tfoot. If they’re not, they’re implicitly nested into a tbody. As in:
<table>
<!-- <tbody> -->
<tr>
<th>Column one</th>
<th>Column two</th>
</th>
<tr>
<td>Row one col one</td>
<td>Row one col two</td>
</th>
<!-- </tbody> -->
</table>
I’ve frequently seen it cause a variety of issues with VDOM libraries, and even plain DOM libraries with a notion of declarative templates, ranging from hydration mismatch logs (meh) to actual logic errors (corruption of the real DOM when nodes aren’t where they’re expected to be).
Other implied/omitted tags like body can cause similar issues too, but I think that’s become a far less common “mistake” (all of these are totally valid since at least HTML5) in recent years.
Annother interesting table one, tr/td/th outside of a <table> will never appear in the DOM. You can make up your own tags and they appear anywhere, but those three are magic and can only exist inside a table.
Forms are also weird, if you leave off the closing tag, an implicit one is included in the DOM. However, if you have inputs further down the page, and technically outside the form, they are included in the submitted form data.
Also fun stuff like you can't have a form inside a form, but if you stick a form inside a form inside a form you end up with a form in a form in the DOM anyways back when I ran into this last.
Other implied/omitted tags like body can cause similar issues too, but I think that’s become a far less common “mistake” (all of these are totally valid since at least HTML5) in recent years.