5 ms·

I think you can generalise the advice: remove as many processing steps as you can. It's not so much that you needed to guess that HTML was going to be as long-

by untog 7y ago

I think you can generalise the advice: remove as many processing steps as you can. It's not so much that you needed to guess that HTML was going to be as long-lived as it is, it's that HTML is the final product that actually loads on the users computer, and those tend to stick around for a long time (or at least be emulated). The code that lives on a backend server somewhere, not so much. For what it's worth, I don't think this example is necessarily bulletproof: it requires a working copy of Frontpage. If Microsoft behaved more like Apple it might have been deprecated away long ago!

btrettel 7y ago
This is one reason why the static site generator I use for my personal website uses HTML rather than something like Markdown. I don't think Markdown is going anyway, incidentally, or that it would be hard to process on my own if I needed to. But the HTML I use is simple enough and Markdown only decreases the probability the site will last a long time.
- dredmorbius 7y ago
  Markdown and/or markdown processors are known to change. Since there's no single Markdown spec, determining just how a page will render, or what will break, is a bit of a crapshoot. And since Markdown treats nonparsable markup as ... plain text, you don't even get errors or other indicators of failure. You've got to view and validate the output manually or by some other means. With formal tag-based markup languages (HTML, SGML, LaTeX, DocBook, etc.) you've at least got 1) an actual markup spec and 2) something that will or won't validate (though whether or not the processor actually gives a damn about that is another question, hello, HTML, I'm looking at your "The Web is an error condition": https://deirdre.net/programming-sucks-why-i-quit/ https://deirdre.net/programming-sucks-why-i-quit/) I can't find the post at the moment, but someone recently wrote a cogent rant on the fact that a change in their hosting provider (GitHub via a static site generator IIRC) had swapped out markdown processors, with changed behaviours, rendering (literally) all their previously-authored content broken. Which is indead a pain. I personally like Markdown, and find it hugely convenient. For major projects though, I suspect what I'll end up doing is starting in Markdown, and eventually switching to a more stable markup format, which probably means LaTeX (HTML has ... proved less robustly stable over the 25+ years I've worked with it). Though for simple-to-modestly-complex documents, Markdown is generally satisfactory, stable, and close enough to unadorned ASCII that fixing what breaks is not a horribly complicated task. Up to modest levels of scale, at least.
  - btrettel 7y ago
    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, let me know. > HTML has ... proved less robustly stable over the 25+ years I've worked with it The first website I made in 2002 still views fine in a modern browser. I didn't do anything fancy, though. I would be interested in what has been unstable as it might give me ideas on what to avoid in HTML. I don't find HTML to be that much harder than plain text or Markdown so I think I'll keep using it for smaller projects. LaTeX is worth considering as well, particularly given that I will have math on some of my webpages. One issue is that the stability of LaTeX depends strongly on which packages you use. I need to take a closer look at the health of every package I use. I think avoiding external dependencies is easier with HTML.
    - 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.
bluGill 7y ago
Google controls the major web engine. I don't trust google to not deprecate parts of html over time because the new shiny is "better". I would rather maintain markdown generators which I can update to change the markup to whatever the latest google insists needs to work instead of rewriting all my documents. I'm currently tasked with writing a UI for a machine that has a 25 year expected lifespan before wear means it is replaced. This is a real concern - think about where computers were 25 years ago and try to find something you are sure will work and look nice.
- rubidium 7y ago
  I sure hope the UI is buttons and not screens :)
- untog 7y ago
  Even if Google did do that (which they’ve shown no signs of, and they are still far from a browser monopoly when you look at iPhone etc) it wouldn’t stop HTML from being read. Translating from HTML -> GoogleHTML wouldn’t be meaningfully different to translating it from Markdown.
  - trilliumbaker 7y ago
    It could be argued that AMP was that attempt, and the only reason AMP gained tractions was Google started using it in the carousel of their SERPs. While Safari, when mobile is included, has ~17% of the market, that's not enough when you combine Google's browser share along with their search engine share.
- trilliumbaker 7y ago
  Google wields too much power. To an extent, they can dictate to website owners what HTML is allowed and not allowed thanks to their dominance in search. This is compounded by the fact that their browser marketshare via Chrome and now Microsoft Edge basically allows them to do what they want with HTML. Matters are even worse. Last year, the W3C became the "yes-man" of Google. They decided to stop developing the HTML standards and just start rubber stamping whatever WHATWG produces. WHATWG is run by Apple, Google, Microsoft, and Mozilla. And who has the most power in that relationship? Yep, Google.

by untog 7y ago

btrettel 7y ago

This is one reason why the static site generator I use for my personal website uses HTML rather than something like Markdown. I don't think Markdown is going anyway, incidentally, or that it would be hard to process on my own if I needed to. But the HTML I use is simple enough and Markdown only decreases the probability the site will last a long time.

dredmorbius 7y ago
Markdown and/or markdown processors are known to change. Since there's no single Markdown spec, determining just how a page will render, or what will break, is a bit of a crapshoot. And since Markdown treats nonparsable markup as ... plain text, you don't even get errors or other indicators of failure. You've got to view and validate the output manually or by some other means. With formal tag-based markup languages (HTML, SGML, LaTeX, DocBook, etc.) you've at least got 1) an actual markup spec and 2) something that will or won't validate (though whether or not the processor actually gives a damn about that is another question, hello, HTML, I'm looking at your "The Web is an error condition": https://deirdre.net/programming-sucks-why-i-quit/ https://deirdre.net/programming-sucks-why-i-quit/) I can't find the post at the moment, but someone recently wrote a cogent rant on the fact that a change in their hosting provider (GitHub via a static site generator IIRC) had swapped out markdown processors, with changed behaviours, rendering (literally) all their previously-authored content broken. Which is indead a pain. I personally like Markdown, and find it hugely convenient. For major projects though, I suspect what I'll end up doing is starting in Markdown, and eventually switching to a more stable markup format, which probably means LaTeX (HTML has ... proved less robustly stable over the 25+ years I've worked with it). Though for simple-to-modestly-complex documents, Markdown is generally satisfactory, stable, and close enough to unadorned ASCII that fixing what breaks is not a horribly complicated task. Up to modest levels of scale, at least.
- btrettel 7y ago
  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, let me know. > HTML has ... proved less robustly stable over the 25+ years I've worked with it The first website I made in 2002 still views fine in a modern browser. I didn't do anything fancy, though. I would be interested in what has been unstable as it might give me ideas on what to avoid in HTML. I don't find HTML to be that much harder than plain text or Markdown so I think I'll keep using it for smaller projects. LaTeX is worth considering as well, particularly given that I will have math on some of my webpages. One issue is that the stability of LaTeX depends strongly on which packages you use. I need to take a closer look at the health of every package I use. I think avoiding external dependencies is easier with HTML.
  - 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.

bluGill 7y ago

Google controls the major web engine. I don't trust google to not deprecate parts of html over time because the new shiny is "better". I would rather maintain markdown generators which I can update to change the markup to whatever the latest google insists needs to work instead of rewriting all my documents. I'm currently tasked with writing a UI for a machine that has a 25 year expected lifespan before wear means it is replaced. This is a real concern - think about where computers were 25 years ago and try to find something you are sure will work and look nice.

rubidium 7y ago
I sure hope the UI is buttons and not screens :)
untog 7y ago
Even if Google did do that (which they’ve shown no signs of, and they are still far from a browser monopoly when you look at iPhone etc) it wouldn’t stop HTML from being read. Translating from HTML -> GoogleHTML wouldn’t be meaningfully different to translating it from Markdown.
- trilliumbaker 7y ago
  It could be argued that AMP was that attempt, and the only reason AMP gained tractions was Google started using it in the carousel of their SERPs. While Safari, when mobile is included, has ~17% of the market, that's not enough when you combine Google's browser share along with their search engine share.
trilliumbaker 7y ago
Google wields too much power. To an extent, they can dictate to website owners what HTML is allowed and not allowed thanks to their dominance in search. This is compounded by the fact that their browser marketshare via Chrome and now Microsoft Edge basically allows them to do what they want with HTML. Matters are even worse. Last year, the W3C became the "yes-man" of Google. They decided to stop developing the HTML standards and just start rubber stamping whatever WHATWG produces. WHATWG is run by Apple, Google, Microsoft, and Mozilla. And who has the most power in that relationship? Yep, Google.