Comment by enriquto

1 day ago

It's not that inconvenient if you omit unnecessary closing tags:

    <tr>
    <td> first
    <td> second
    <tr>
    <td> what
    <td> ever

I find it simpler and cleaner than any of the markdown table markups

15 comments

enriquto

Reply
sedatk  1 day ago

> if you omit unnecessary closing tags

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.

  • rebane2001  6 hours ago

    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.

  • troad  17 hours ago

    > <br/>

    Only occasionally? I will die on this hill.

    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.

    • myfonj  6 hours ago

      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.

      Also, https://jakearchibald.com/2023/against-self-closing-tags-in-... provides a broad perspective on the topic (but I guess it is very unlikely anyone reading this hasn't seen that article already).

      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.

      2 replies →

myfonj  1 day ago

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:

    <table><tr><th>Term 1<td>Definition 1
           <tr><th>Term 2<td>Definition 2
    </table>
    <dl><dt>Term 1<dd>Definition 1
        <dt>Term 2<dd>Definition 2
    </dl>