4 ms·

It's not that inconvenient if you omit unnecessary closing tags: <tr> <td> first <td> second <tr> <td> what <td> ever I find it simple

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

debesyla 4mo ago
Isn't markdown table just a bunch of | ?
- zufallsheld 4mo ago
 That's the problem.
 - froh 4mo ago
 most specifically the problem is that markdown tables don't allow breaking the table row in multiple lines but then you can always use HTML tables in markdown and Pandoc transforms it just fine
 - jazzypants 4mo ago
 Every markdown implementation is supposed to allow inline HTML.
 - hnlmorg 4mo ago
 has worked fine whenever I’ve needed line breaking in markdown tables
 - xigoi 4mo ago
 They mean in the Markdown code, not in the output.
 - quietbritishjim 4mo ago
 I think they mean breaking the line in the markup, not the output
 froh 4mo ago
 yes, that's what I meant, indeed.
myfonj 4mo 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>
sedatk 4mo 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 ` ` like ` ` out of habit.
- troad 4mo ago
 > 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 4mo 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 ` ` (and even ` ` 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-html/ 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 ` ` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using ` ` 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 ` `. 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 ` ` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.

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

debesyla 4mo ago

Isn't markdown table just a bunch of | ?

zufallsheld 4mo ago
That's the problem.
- froh 4mo ago
 most specifically the problem is that markdown tables don't allow breaking the table row in multiple lines but then you can always use HTML tables in markdown and Pandoc transforms it just fine
 - jazzypants 4mo ago
 Every markdown implementation is supposed to allow inline HTML.
 - hnlmorg 4mo ago
 has worked fine whenever I’ve needed line breaking in markdown tables
 - xigoi 4mo ago
 They mean in the Markdown code, not in the output.
 - quietbritishjim 4mo ago
 I think they mean breaking the line in the markup, not the output
 - froh 4mo ago
 yes, that's what I meant, indeed.

myfonj 4mo 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>

sedatk 4mo 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 ` ` like ` ` out of habit.

troad 4mo ago
> 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 4mo 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 ` ` (and even ` ` 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-html/ 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 ` ` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using ` ` 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 ` `. 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 ` ` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.