I love DL. I think tables, at least in the past, were misused as DLs even more in the past and the inconvenience of the table markup is even worse than a bunch of divs.
As someone who had written lots of XHTML in the past, not having closing tags makes my eyes twitch like Scrat in Ice Age. I even occasionally write `<br>` like `<br/>` out of habit.
Yes yes, someone is about to tell me that Opera running on a PS Vita with the language set to Basque will display those incorrectly. That ISO 714-4BΔ-鸡冠 defines them as undefined, and prohibits them within eight clock ticks of C sequence points. That Apple charges an extra 1% app store commission for them (except where prohibited by court injunction).
Call it a concession to my sanity. A song of saner days.
Someone here. OP most certainly knows that precisely, but for the rest: It was Netscape® Communicator, which interpreted everything after `<` up to either white-space or `>` as a tag name. Technically that wasn't even that much incorrect, but amusingly, since the HTML "specs" then still stemmed from SGML, the really correct outcome of `<br/>` (and even `<br />` with a space before the "closing" solidus) back then should have been to both emit the (empty, by definition) BR element (⁕) and a dangling `>` text node after that. No consumer-facing HTML client really implemented that. Netscape simply took it as unknown "BR/" tag and didn't render anything in its place.
In the late '90s Netscape was a niche browser with negligible 80% market share. The real and eternal XHTML enlightenment had begun a few years later, in the early 2000s and reached near eternal duration of seven years.
Practically, using `<br />` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using `<br/>` is safe since around 2002-2008 when Netscape was dying. In 2026, you can throw basically anything at current browsers and it will repair it to something meaningful, as per the living HTML spec. You can go `</br/r/r>`, if you are really into solidi, and it will work the same as `<br>`.
Disclosure: I also clearly see how having stupid simple "XML-like" syntactic rules would be beneficial in the grand scheme of things compared to what HTML became: memorising the "VOID" HTML elements by heart, and having to implement this in every HTML processing product clearly creates significant mental and processing overhead. But FMPoV, it's just one inconvenience we should begrudgingly accept at this point, rather than fight it.
(⁕) In reality, the way browsers treat `<br>` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.
Haha, blushing in awkward uncertainty that I've failed to detect irony …? (Is this HN, right?) But even if, thanks anyway! I'm glad I could vent the lore I've spent gathering in unhealthy amount of unproductive research; I cannot imagine better place to finally bury that than deep in super-tangential HN discussion…
You cannot close HTML tags that way anyways, <br> and <br/> are the same, as are <div> and <div/>. The spec defines whether an element self-closes, the slash is just ignored.
Fair point, though /DT and /DD are also optional just like /TH, /TD and /TR are. So in effect, def…scription list could structurally save you one TR for each entry and two "BLE"s: