8 ms·

Saying HTML can be offlineable is like saying C can be provably terminating. There's a subset of programs where that's true, but it's not inherent to the form.

Saying HTML can be offlineable is like saying C can be provably terminating. There's a subset of programs where that's true, but it's not inherent to the form. A PDF is inherently self-contained, standard web technologies are not. When you open the page and it's a PDF, it gives you certain guarantees, when you open it and it's HTML, you have to have to do further investigation.

monkeynotes 5y ago
I don't buy that the problem with the web is that HTML is not inherently offlineable. HTML may not be inherently offlineable but it can be. PDF isn't inherently a web friendly format, but it can be. There really isn't any good argument for PDFing the web.
- pajko 5y ago
  Print the page to PDF.
  - tablespoon 5y ago
    > Print the page to PDF. Even that usually sucks nowadays, because web developers don't care anymore. Probably 75% of the time before I do that, I have to go into the dev console to delete overlay elements that obscure content and garbage that will waste 10 pages (e.g. grossly oversized images, related article recommendations, etc.). There was a time when most websites had a print view that gave you a simplified html page that worked well, but I think most of those are gone now. Now it's all some print "media-type" CSS that no one ever put the time in to do properly or keep up to date.
EugeneOZ 5y ago
> A PDF is inherently self-contained, standard web technologies are not What technologies exactly? You can have absolutely everything you need inside the HTML. You can inline css, js, svg and images. What technologies you can’t inline?
- aenigma 5y ago
  you are correct that you CAN - but who does. That's no longer considered best practice. The arugment these days is that it's a lot easier to manage css if it's in a separate file, same with js, etc. So none of the serious web developers actually do anything inline anymore. The time it would take to convert a "best practice" website with separate files for html, css, js, etc. is just not worth it. The point he's making is still valid - why not have the option for something static.
  - EugeneOZ 5y ago
    But with the same (and even much bigger) success you can declare “I’m switching to self-contained HTML! No more external resources!” instead of “I’m switching to PDF, saying farewell to interactivity and mobile devices”. It's just the declaration of ONE person, switching ONE site.
  - apotheon 5y ago
    > why not have the option for something static You have the same option with either HTML or PDF: - PDF files can be dynamic or static, depending on how you write them. - HTML files can be dynamic or static, depending on how you write them.
lucideer 5y ago
Firstly, C being provably terminating is a problem dealing with the full body of C programs written in the world. The OP is dealing with their own self-published content. That's a different problem: if your analogy held it would need to be limited to proving that a subset of C programs written by the author terminate. Secondly, the level of difficulty in making HTML offlineable is many orders of magnitude simpler than your C analogy: there's really no comparison. For the OP we only need to make HTML documents that they have authored themselves offlineable and yet people have written general purpose tools to do this automatically for most webpages. This is not a hard problem. TL;DR your analogy is absurd.
- hyperpape 5y ago
  This is a helpful post because it gets to the heart of the difference. Many people are saying "if you do HTML in a particular way, you get the same benefits." I'm asking "what's inherent to the form?" That's exactly the point about C--you can write it in a way that's provably terminated, but it's not guaranteed. Consider the consumer's perspective. When I land on a page that's a PDF, I know certain things--I can easily save it and read it later. How do I know that? Not because I have read the PDF spec, or know that much about it, but because of my experience as a consumer of the web. When I land on an arbitrary web-page, do I know the same thing? No. I don't know what the page is doing, I don't know what my browser will do when I try to save the page. When I save this page, I have the option to save HTML only, or a complete web page. Will the complete page actually work? I go into the source, and there's a link to the javascript (which is saved locally). Does rendering the page rely on that javascript? Does that javascript do xhr or fetch calls? Since it's Hacker News, I suspect the answer is no. However that's not inherent to the medium. There are better ways to archive the content of even dynamic JS heavy pages, but they are not things that you learn as an average user of the web.
  - lucideer 5y ago
    I don't really follow. How does this author converting their entire site to PDF help readers/visitors/users? The original HTML site[0] was printable as PDF, and save-able as both HTML and "Web page, complete", all of which result in a well-formatted & readable offline experience. (It was also responsive: very readable on mobile, but that's an aside). The new PDF site is not accessible to some, difficult to read on mobile, and interacts poorly with all of the norms web users are accustomed to (back navigation, anchors, etc.) [0] https://web.archive.org/web/20130127175816/http://www.lab6.com/old/nossy1-10.html https://web.archive.org/web/20130127175816/http://www.lab6.c...
JadeNB 5y ago
> When you open the page and it's a PDF, it gives you certain guarantees …. I think that this is a lot less true than we're used to thinking. The PDF spec contains a lot more interactive capabilities than I think most people realise. (It supports JavaScript!) We're not used to seeing those capabilities abused, because there's no point; it is so much easier to abuse HTML. But, if people want to abuse PDF—and, if we somehow convinced the world to move to it, then they would—then they easily can. (I'm not conversant enough in the spec to know, but I do know that Postscript is Turing complete, and I don't know that PDF isn't. At least HTML on its own certainly isn't—no recursion!—although all bets go out the window once you start layering other tech on top of it.)
stjohnswarts 5y ago
I agree, I don't see why anyone can call publishing in PDF is "dumb". The author of the material gets to choose his medium. If "you" don't like it then move along or convert it to your preferred format. In other words "why not both?"
- hypertele-Xii 5y ago
  I bet HTML to PDF is a lot easier conversion than PDF to HTML. Formats matter.

monkeynotes 5y ago

I don't buy that the problem with the web is that HTML is not inherently offlineable. HTML may not be inherently offlineable but it can be. PDF isn't inherently a web friendly format, but it can be. There really isn't any good argument for PDFing the web.

pajko 5y ago
Print the page to PDF.
- tablespoon 5y ago
  > Print the page to PDF. Even that usually sucks nowadays, because web developers don't care anymore. Probably 75% of the time before I do that, I have to go into the dev console to delete overlay elements that obscure content and garbage that will waste 10 pages (e.g. grossly oversized images, related article recommendations, etc.). There was a time when most websites had a print view that gave you a simplified html page that worked well, but I think most of those are gone now. Now it's all some print "media-type" CSS that no one ever put the time in to do properly or keep up to date.

EugeneOZ 5y ago

> A PDF is inherently self-contained, standard web technologies are not What technologies exactly? You can have absolutely everything you need inside the HTML. You can inline css, js, svg and images. What technologies you can’t inline?

aenigma 5y ago
you are correct that you CAN - but who does. That's no longer considered best practice. The arugment these days is that it's a lot easier to manage css if it's in a separate file, same with js, etc. So none of the serious web developers actually do anything inline anymore. The time it would take to convert a "best practice" website with separate files for html, css, js, etc. is just not worth it. The point he's making is still valid - why not have the option for something static.
- EugeneOZ 5y ago
  But with the same (and even much bigger) success you can declare “I’m switching to self-contained HTML! No more external resources!” instead of “I’m switching to PDF, saying farewell to interactivity and mobile devices”. It's just the declaration of ONE person, switching ONE site.
- apotheon 5y ago
  > why not have the option for something static You have the same option with either HTML or PDF: - PDF files can be dynamic or static, depending on how you write them. - HTML files can be dynamic or static, depending on how you write them.

lucideer 5y ago

Firstly, C being provably terminating is a problem dealing with the full body of C programs written in the world. The OP is dealing with their own self-published content. That's a different problem: if your analogy held it would need to be limited to proving that a subset of C programs written by the author terminate. Secondly, the level of difficulty in making HTML offlineable is many orders of magnitude simpler than your C analogy: there's really no comparison. For the OP we only need to make HTML documents that they have authored themselves offlineable and yet people have written general purpose tools to do this automatically for most webpages. This is not a hard problem. TL;DR your analogy is absurd.

hyperpape 5y ago
This is a helpful post because it gets to the heart of the difference. Many people are saying "if you do HTML in a particular way, you get the same benefits." I'm asking "what's inherent to the form?" That's exactly the point about C--you can write it in a way that's provably terminated, but it's not guaranteed. Consider the consumer's perspective. When I land on a page that's a PDF, I know certain things--I can easily save it and read it later. How do I know that? Not because I have read the PDF spec, or know that much about it, but because of my experience as a consumer of the web. When I land on an arbitrary web-page, do I know the same thing? No. I don't know what the page is doing, I don't know what my browser will do when I try to save the page. When I save this page, I have the option to save HTML only, or a complete web page. Will the complete page actually work? I go into the source, and there's a link to the javascript (which is saved locally). Does rendering the page rely on that javascript? Does that javascript do xhr or fetch calls? Since it's Hacker News, I suspect the answer is no. However that's not inherent to the medium. There are better ways to archive the content of even dynamic JS heavy pages, but they are not things that you learn as an average user of the web.
- lucideer 5y ago
  I don't really follow. How does this author converting their entire site to PDF help readers/visitors/users? The original HTML site[0] was printable as PDF, and save-able as both HTML and "Web page, complete", all of which result in a well-formatted & readable offline experience. (It was also responsive: very readable on mobile, but that's an aside). The new PDF site is not accessible to some, difficult to read on mobile, and interacts poorly with all of the norms web users are accustomed to (back navigation, anchors, etc.) [0] https://web.archive.org/web/20130127175816/http://www.lab6.com/old/nossy1-10.html https://web.archive.org/web/20130127175816/http://www.lab6.c...

JadeNB 5y ago

> When you open the page and it's a PDF, it gives you certain guarantees …. I think that this is a lot less true than we're used to thinking. The PDF spec contains a lot more interactive capabilities than I think most people realise. (It supports JavaScript!) We're not used to seeing those capabilities abused, because there's no point; it is so much easier to abuse HTML. But, if people want to abuse PDF—and, if we somehow convinced the world to move to it, then they would—then they easily can. (I'm not conversant enough in the spec to know, but I do know that Postscript is Turing complete, and I don't know that PDF isn't. At least HTML on its own certainly isn't—no recursion!—although all bets go out the window once you start layering other tech on top of it.)

stjohnswarts 5y ago

I agree, I don't see why anyone can call publishing in PDF is "dumb". The author of the material gets to choose his medium. If "you" don't like it then move along or convert it to your preferred format. In other words "why not both?"

hypertele-Xii 5y ago
I bet HTML to PDF is a lot easier conversion than PDF to HTML. Formats matter.