I reckon it does hurt, beyond the negligible cost of the extra transferred and parsed bytes: it teaches something that’s simply incorrect, and doesn’t do what people often think it does.

① The trailing slash doesn’t make a tag self-closing. All it does is get ignored, emitting a parse error (which in common compiler terms is just a warning) if you use it on a non-void tag.

You can’t use <div/>. You can’t use <custom-tag/>. The only tags you’re allowed to use the trailing slash on are the defined void tags like <img> and <br>.

It’s not “not necessary”, it’s “completely useless, by definition”.

I’ve seen people presume they can close tags this way. JSX probably helps cause this, because you can there. But because self-closing tags aren’t a thing in HTML syntax, I think it’s harmful to use the spelling at all in HTML syntax.

② I wouldn’t mind so much if people used it consistently, and I wouldn’t mind at all if it was being used to support both HTML and XML syntax, but if you see sites that use trailing slashes on void tags in their head, practically every time there will be at least one tag that isn’t using it:

  <link … />
  <meta … />
  <link …>
  <link … />

③ I also dislike it because it’s fairly common for syntax highlighters or other casual parsers to get it wrong. Most commonly, I’ve seen tools misinterpret an unquoted last attribute, treating <a href=/example/> as <a href="/example" /> rather than <a href="/example/"> before. (Same with the likes of <img src=/example/>, but anchor hrefs are more commonly going to look like that.)

IIRC, that's not necessarily true, some parsers "upgrade" html to xhtml and then process the xhtml since its more regular. html in general is a mess due to backwards compatibility requirements so trying to follow these kind of definitions imo is kinda pointless. you can optimize for size if you want but the decrease from these kind of optimizations with modern speeds is rather minimal

> some parsers "upgrade" html to xhtml and then process the xhtml since its more regular.

I have never heard of anything even vaguely matching your description, and it would be wildly wrong. HTML parsing is exhaustively defined, and the only way of correctly parsing HTML is to use the defined HTML parser.

I strongly believe that the harm we experienced from XHTML should not be passed down to future generations.

You didn't love the strict and unhelpful generic XML exception you got when you accidentally forgot to close a tag?

Don't blame bad tools on the language.

I thought the whole point of XML tags coming in named pairs was so you could be helpfully told which tag wasn't closed?

XHTML was a move by Big CMS to make edit-and-FTP error prone. Before that you rarely had to care whether the tag was closed.

Is this a joke? I genuinely can't tell.

Tell me you weren't there without telling me you weren't there. Big CMS hated it.

I've always been completely baffled by the rejection of xhtml. It gave a way to extend html with new elements and a simple, powerful client side templating language with xslt. The "reason" for which I remember it being rejected was that allegedly web devs couldn't wrap their heads around closing tags and explicit attribute values, which seems crazy to me. Then a few years later typescript took off (which is way more complicated) and react gave a pretend way to write xml except now you need a compiler/build pipeline, and everyone loved it.

xhtml still works in modern browsers btw. It's still probably the easiest way to do page templates. XSLT shows its age without the ability to modify the page after load (unless you run it via javascript), but we could've just added that and it'd be almost perfect.