4 ms·

I appreciate your reply. Seems Markdown is more complex than I recognized and this just makes me want to avoid it more. If you do find the rant you mentioned, l

• dredmorbius 7y ago
  My sense is that Markdown is probably pretty safe for most uses, particularly if you control the processing. If not, then yes, it can bite. For me that means pandoc to generate endpoints such as HTML, PDF, etc. I'm fairly confident that most of that toolchain should continue to work (provided computers and electricity exist) for another 2-4 decades. For certain more complex formatting, Markdown has limitations and features are more likely to change. But I've used Markdown to format novel-length works (from ASCII sources, for my own use) with very modest formatting needs (chapters, some italic or bold text, possibly blockquotes or lists), and it excels at that. For HTML, it's a combination of factors: - Previous features which have been dropped, most to thunderous applause. (<blink>, <marquee>, etc.) - Previous conventions which have largely been supersceded: table layouts most especially. CSS really has been ... in some respects ... a blessing. - Nagging omissions. The fact that there's no HTML-native footnoting / endnoting convention ... bothers me. You can tool that into a page. But you can't simply do something like: <p>Lorem ipsum dolor sit amet. <note>Consectetur adipiscing elit</note> Nulla malesuada, mauris ac tincidunt faucibus</p> ... and have the contents of <note> then appear by some mechanism in the rendered text. A numbered note, a typographical mark ( * † ‡ ...), a sidenote, a callout, a hovercard, say. In Markdown you accomplish this by: Lorem ipsum dolor sit amet.[^consectetur] Nulla malesuada, mauris ac tincidunt faucibus [^consectetur]: Consectetur adipiscing elit. Which then generates the HTML to create a superscript reference, and a numbered note (when generating HTML). Or footnotes according to other conventions (e.g., LaTeX / PDF) for other document formats. - Similarly, no native equation support. Maybe I'm just overly fond of footnotes and equations.... But HTML and WWW originated, literally, from the world's leading particle physics laboratory. You'd think it might include such capabilities. - Scripting and preprocessors. I remember server-side includes, there's PHP, and JS. Some browsers supported other languages -- I believe Tcl and Lua are among those that have been used. Interactivity and dependency on other moving parts reduces reliability. The expression "complexity is the enemy of reliabilty" dates to an Economist article in 1958. It remains very, very true. HTML is for me more fiddly than Markdown (though I've coded massive amounts of both by hand), so on balance, I prefer writing Markdown (it's become very nearly completely natural to me). OTOH, LaTeX isn't much more complex than HTML, and in many cases (simple paragraphs) far simpler, so if I had to make a switch, that's the direction I'd more likely go.
  • btrettel 7y ago
    I agree with you entirely on the abandoning of conventions with HTML. I haven't paid much attention to multi-column layouts in CSS over the years but my impression is that it's gone from tables to CSS floats to whatever CSS does now that I'm not familiar with. Browsers are typically backwards compatible so this isn't that big of a deal to me. But I have no idea if what's regarded as the best practice today will be seen as primitive in 15 years. > The fact that there's no HTML-native footnoting / endnoting convention ... bothers me. I've seen people use the HTML5 <aside> element for sidenotes, styled with CSS. Some even make them responsive, folding neatly into the text as the viewport shrinks. I'm not sure if this is the intended use for <aside> but the result is reasonable and I intend to do the same. If you're set on footnotes, though, yes, I don't know a native implementation. Equation support with MathML is okay in principle but not practice. I'd like to have equations without external dependencies (MathJax's JS alone is like 750 kB!), but that's not possible until Chrome decides to catch up with Firefox and Sarafi on MathML. I've been thinking about just using MathML as-is (no external math renderer), and if Chrome users complain, I'll tell them to get a better browser. ;-) Maybe that'll help some Chrome users understand why they should test their websites in other browsers.
    • dredmorbius 7y ago
      CSS columns are actually ... mostly ... pretty useful: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Columns/Using_multi-column_layouts https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Columns... My preference is to use them with @media queries to create more or fewer columns within auxiliary elements (headers, footers, asides), usually to pretty good effect. Multi-column body text is largely an abombination. For images, I'm still largely sticking to floats. I've done some sidenote styling that I ... think I like. I don't remember how responsive this CodePen is or isn't though I've created some pretty responsive layouts based on it: https://codepen.io/dredmorbius/full/OVmKZX https://codepen.io/dredmorbius/full/OVmKZX I consider equation support a lost cause.
    • WorldMaker 7y ago
      Semi-relatedly, I think even the linear form of UnicodeMath [1] is very readable, and it would be great if there was more support for building it up into nicer presentation forms in the browser wild (MathJax has had it on the backlog since at least 2015, for instance), as that seems to me to be a better "fallback" situation than raw MathML given its readability when not built up. [1] http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf > I haven't paid much attention to multi-column layouts in CSS over the years but my impression is that it's gone from tables to CSS floats to whatever CSS does now that I'm not familiar with. CSS Grid [2] is the happiest path today. It's a really happy path (I want these columns, this wide, done). CSS Flexbox [3] is a bit older and nearly as happy a path. Some really powerful things can be used with the combination of both, especially in responsive design (a dense two dimensional grid on large widescreen displays collapsing to a simple flexbox "one dimensional" flow, for example). Flexbox may be seen as primitive in a few years, but Grid finally seems exactly where things should have always been (and what people were trying to accomplish way back when with tables or worse framesets). Even then, Flexbox may be mostly seen as primitive from the sense of "simple lego/duplo tool" compared to Grid's more precise/powerful/capable tools. [2] https://caniuse.com/#feat=css-grid https://caniuse.com/#feat=css-grid [3] https://caniuse.com/#feat=flexbox https://caniuse.com/#feat=flexbox