<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>lucideer</author><text>&amp;gt; &lt;i&gt;you have to understand auto-closing behaviour either way&lt;/i&gt;&lt;p&gt;You do, if you use HTML, but my read of the above two comments was that they would&amp;#x27;ve preferred if the world had stuck on the XHTML path.&lt;p&gt;&amp;gt; &lt;i&gt;Now with XHTML, that&amp;#x27;s a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays.&lt;/i&gt;&lt;p&gt;Actually, XHTML is a (little-known) part of the HTML5 spec.[0], so going the strict path is still an option. In the past, this would&amp;#x27;ve required complex content-negotiation for media-type backward-compat but that&amp;#x27;s no longer an issue unless a non-neglible % of your visitors are using IE8.&lt;p&gt;The only remaining issue is that of draconian error handling, which is an issue browsers definitely would have fixed the UX of had the mainstream stayed on the XHTML track, but sadly that never happened. Still, good modern support for server-side validation of well-formed XML documents means this is also less of an issue than it once was (though tbh, still a significant issue imo).&lt;p&gt;W3 have also put together a more informal guide to modern XHTML considerations within the HTML5 spec. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;dev.w3.org&amp;#x2F;html5&amp;#x2F;html-polyglot&amp;#x2F;html-polyglot.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;dev.w3.org&amp;#x2F;html5&amp;#x2F;html-polyglot&amp;#x2F;html-polyglot.html&lt;/a&gt;&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;html.spec.whatwg.org&amp;#x2F;multipage&amp;#x2F;xhtml.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;html.spec.whatwg.org&amp;#x2F;multipage&amp;#x2F;xhtml.html&lt;/a&gt;</text><parent_chain><item><author>vbezhenar</author><text>It&amp;#x27;s not a good idea to close all elements in HTML because browser does not care about your closing elements, they&amp;#x27;ll be closed automatically regardless of whether you closed them or not. And your closed elements will be opened automatically.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;List: &amp;lt;ul&amp;gt;&amp;lt;li&amp;gt;item1&amp;lt;&amp;#x2F;li&amp;gt;&amp;lt;&amp;#x2F;ul&amp;gt; of items&amp;lt;&amp;#x2F;p&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
becomes&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;List: &amp;lt;&amp;#x2F;p&amp;gt;&amp;lt;ul&amp;gt;&amp;lt;li&amp;gt;item1&amp;lt;&amp;#x2F;li&amp;gt;&amp;lt;&amp;#x2F;ul&amp;gt; of items&amp;lt;p&amp;gt;&amp;lt;&amp;#x2F;p&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
and that&amp;#x27;s probably not what you wanted. So you have to understand auto-closing behaviour either way. And if you understand it, you can just spare yourself from closing them.&lt;p&gt;Now with XHTML, that&amp;#x27;s a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays.</text></item><item><author>dataflow</author><text>+1 for XHTML. I never understood why people think it&amp;#x27;s a good idea to avoid closing elements. It&amp;#x27;s like a dangling brace to me... it nags me and it just doesn&amp;#x27;t look right. How is it seen as acceptable practice?</text></item><item><author>Gehinnn</author><text>With this amount of exceptions in the specification, it is no wonder that people find unexpected combinations of different features to exploit stuff.&lt;p&gt;I know why I don&amp;#x27;t like automatically closing elements. Xhtml for the win!</text></item></parent_chain></comment><story><title>DOMPurify bypass: XSS via HTML namespace confusion</title><url>https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>cookiengineer</author><text>&amp;gt; they&amp;#x27;ll be closed automatically regardless of whether you closed them or not.&lt;p&gt;Actually that is not really true. It is defined per html5 spec what is closed automatically when another open node is being parsed.&lt;p&gt;The &amp;lt;p&amp;gt; element always had a weird flow-root behaviour, that is why it is always closed automatically.&lt;p&gt;Rather than that iirc mostly form relevant elements are also closed automatically, like optgroup, option, select, input and such.&lt;p&gt;Additionally it&amp;#x27;s only table (same problem with flow root) and body, pretty much.&lt;p&gt;I can understand that a lot of people are confused why that is. But the reason is not the difference of XML vs SGML per se (xhtml will simply break if a p is within a p)... it&amp;#x27;s the flow root model and the difference in behaviours of layouting that is specified here, not the notation structure.&lt;p&gt;So SGML was the better choice, to allow all php crapsites that never test their html validity to still run rather than forcing the enduser to (fix?) the xml.&lt;p&gt;I mean, at some point opera didn&amp;#x27;t even work on bbcode based forum software(s), so people quickly started abandoning it.</text><parent_chain><item><author>vbezhenar</author><text>It&amp;#x27;s not a good idea to close all elements in HTML because browser does not care about your closing elements, they&amp;#x27;ll be closed automatically regardless of whether you closed them or not. And your closed elements will be opened automatically.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;List: &amp;lt;ul&amp;gt;&amp;lt;li&amp;gt;item1&amp;lt;&amp;#x2F;li&amp;gt;&amp;lt;&amp;#x2F;ul&amp;gt; of items&amp;lt;&amp;#x2F;p&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
becomes&lt;p&gt;&lt;pre&gt;&lt;code&gt;    &amp;lt;p&amp;gt;List: &amp;lt;&amp;#x2F;p&amp;gt;&amp;lt;ul&amp;gt;&amp;lt;li&amp;gt;item1&amp;lt;&amp;#x2F;li&amp;gt;&amp;lt;&amp;#x2F;ul&amp;gt; of items&amp;lt;p&amp;gt;&amp;lt;&amp;#x2F;p&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
and that&amp;#x27;s probably not what you wanted. So you have to understand auto-closing behaviour either way. And if you understand it, you can just spare yourself from closing them.&lt;p&gt;Now with XHTML, that&amp;#x27;s a different thing. But I think that ship sailed many years ago and HTML is a preferred way to go nowadays.</text></item><item><author>dataflow</author><text>+1 for XHTML. I never understood why people think it&amp;#x27;s a good idea to avoid closing elements. It&amp;#x27;s like a dangling brace to me... it nags me and it just doesn&amp;#x27;t look right. How is it seen as acceptable practice?</text></item><item><author>Gehinnn</author><text>With this amount of exceptions in the specification, it is no wonder that people find unexpected combinations of different features to exploit stuff.&lt;p&gt;I know why I don&amp;#x27;t like automatically closing elements. Xhtml for the win!</text></item></parent_chain></comment><story><title>DOMPurify bypass: XSS via HTML namespace confusion</title><url>https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/</url></story>