<g> is interesting there: it’s an SVG element. SVG and MathML are fun in HTML syntax, because it becomes a little more XMLly when parsing them: XML-style self-c

<g> is interesting there: it’s an SVG element. SVG and MathML are fun in HTML syntax, because it becomes a little more XMLly when parsing them: XML-style self-closing tags (<tag/>) actually work, and there’s no such thing as a void element (e.g. <br> which has no closing tag because it has no contents). This can lead to fun problems in overly-simplistic filtering, e.g. <script/>alert()</script> is a syntax error in SVG or in XML-syntax HTML, is swallowed and does nothing inside SVG-in-HTML (it’s an empty script tag followed by a text node and an extraneous end tag), and alerts inside HTML (the trailing slash in the start tag reports a syntax error but they don’t do anything). This is ripe for security issues from smuggling stuff. There’s also fun like whether <script>alert("<")</script> alerts “<” (SVG/XML-syntax HTML) or “<” (HTML). These sorts of things are why it is said: use a real HTML parser if you’re working with HTML. In the rest of HTML syntax, adding a trailing slash does exactly nothing—it’s just ignored by the parser¹. For my part, I firmly recommend against writing it if you’re using HTML syntax, because it gives the false impression that it does something; rather, there’s a hard-coded list of elements that have no contents and thus no closing tag. It’s not uncommon to find people writing their />, but it’s practically never consistently applied, e.g.: <meta charSet="utf-8"/> ← ² <link rel="…" href="…"/> <link rel="…" href="…"> ← Where’s my /, hmm? So if you tried loading this with XML syntax (which is still very much a thing), you’d hit a parse error. And remember, this was put in as an XHTML compatibility measure (though I’m honestly not convinced it was worth it—without the special handling, you’d just have ended up with an attribute named / with an empty string value, which isn’t so bad). HTML/XML polyglot is a surprisingly thorny issue, and my experience is that a lot of JavaScript libraries make assumptions that don’t hold in XML-syntax documents and thus won’t work properly. In practice, almost no one uses XML syntax for anything new, and foreign content (SVG/MathML) is the last remnant of widely-used XML in HTML. —⁂— ¹ This is a very slight simplification. Look into the self-closing flag in the spec if you’re interested in the details. ² I think that wrong capitalisation of charSet comes from Next.js, because every time I’ve seen it, Next.js has been present. It has irritated me for years, but never quite enough to dig in and find the source and beg them to fix it. No idea if Next.js supports using XML-syntax HTML, but if it does, that meta charSet will be invalid, because XML syntax is case-sensitive and it’s supposed to be charset—though I think it will still work in practice because of the charset detection algorithm actually working on the bytes, not the XML/HTML syntax, and being case-insensitive. And if Next.js doesn’t support using XML syntax, I wish they’d stop generating trailing slashes, too, because they’re just a waste of time.