One of the hardest things I remember from my time as a web consultant was explaining to my customers why PDF is not a suitable replacement for HTML. They always tried to replace half of their pages with pdf documents...
Well don't leave us in suspense, why isn't PDF a suitable replacement?
* If your internal workflow is designing documents then the conversion to a web document will be clunky at best.
* Every end-user device has a PDF reader and their web browser probably opens it transparently.
* You need the PDF either way way because the website will never be the authoritative source so now you have the problem of making sure they don't get out of sync.
* You probably have a few internal graphic designers that can do wonders with print but it's unlikely you have an internal web development team.
* It's much easier to make a PDF accessible than a website. (Before you disagree remember that the offices we're talking about likely don't have a dedicated web designer) You can be sure it will print correctly, and for most users it's automatically offline.
Since I was specifically asked, yes, the OP covers my main arguments quite nicely. But in essence, I would argue the web is content-oriented, and the PDF is not.
For example,
1. The web is a medium where you cannot (within reason) exercise too much control over the design of things. You lay out general guidelines that tell the browser how to render whatever content is thrown at it. I won't pretend this gets us predictable design, but at least it's uniform, which is good for human consumption.
2. The web is a medium that lends itself to structural document construction in such a way that it is easy to use and reuse the content in ways not anticipated. This is good for machine consumption, which in turn empowers the human.
These arguments may seem philosophical, but they do have real-world effects. Once I managed to explain it in ways the customer understood, they were always eager to be of assistance in the endeavour.
As long as we're speaking in idealistic terms I pretty much agree with you but when you compare websites and PDFs that exist in practice it tells a different story.
Zooming PDFs on mobile can be a pain but it's certainly less of a pain than using some fixed width site from the early 2000s with a jQuery menu you can only operate with a mouse and links so small that a mouse would fat finger them.
Machine consumption of the documents is one of those benefits that sounds cool but really just boils down to SEO because very few other things are going to be scraping your site. Certainly worth something but it's usually not high on the priority list for governments and search bots scrape PDFs anyway.
I think the main point in favor of the web is that you can have multiple presentation layers for the same underlying content and you can improve presentation independently of content. Not necessarily that it's reusable because that's just templates and a style guide but that you can backport all your fixes.
Seems a little tautological. I mean the web is certainly an interlinked set of documents but nothing really says they have to be HTML. I mean people around here link to arXiv all the time and that's essentially just a repository of PDFs. Browsers just get you to the content, doesn't mean it has to be able to display all of it.
I don't think it's that people don't want to change, you're still going to need print designs regardless and it's much easier to host a print design than it is to convert a website into one.
> Everyone that can design a PDF can learn to design a nice HTML document.
I mean I wish that was true. I think people can learn to write content in a web compatible way but a designer that spends all their time in PS and ID isn't going to suddenly be able to crank out high quality web pages.
Let's take perhaps the simplest most important accessibility feature:
How do I increase the font size without making the content absurdly wide, while viewing a PDF?
As a visually impaired user, this is my single biggest gripe with PDFs. Its also annoying that zooming on many websites completely breaks the layout, often overlapping text or pushing important elements off of the screen. I find this particularly sad, since HTML largely supports a separation of content and presentation.
In the Adobe Reader app for Android on the bottom right you can select multiple 'view modes' one called 'Reader Mode' which will allow you to reflow a document and increase the font size considerably. I capped it out at about a letter per screen.
Sure, but that's because mobile devices have really small screens. You could create PDFs that were meant to be viewed at that size, but why?
You'd have the same problem trying to read a regular book through a mobile-phone-sized window. That doesn't make books an unsuitable vehicle for document delivery.
Not at all; there is no information that people won't want to access from a mobile device. But again, a mobile device is not necessarily suitable for the job.
Mobile devices works perfectly well for accessing this kind of information when developers aren't outright hostile to the users they are meant to serve.
It's not a developers job to tell me whether or not my device is suitable for reading their information because they can't be bothered to make it available as HTML.
> a mobile device is not necessarily suitable for the job.
Certainly not if the publishers took that attitude. And what you consider suitable simply isn't relevant if half the audience is now using a mobile device.
If you click on a link to a .pdf in Safari on iOS (certainly on iOS 11, but I'm pretty sure many versions prior to that) it will transparently show the PDF within the browser (it's a fast native PDF viewer that can be zoomed/scrolled very easily).
PDF is easy to create from a Word document, try using Word to create HTML and you get a dogs dinner. If our industry was better at creating tools for ordinary users to create HTML then the problem would solve itself.
The issue is that people want a frozen format so they can line up images precisely where they want them to be. This is antithetical to displaying things in a browser. Sure, it can be done, but it's CSS that's fighting the browser.
What we really should have done for our governments is figured out the 20 or so essential layouts and pre-coded CSS for them, but always allowed the government to fallback to custom HTML / CSS.
Never mind that shifting one of them produces a cascade of changes that leads to some office worker spending a fruitful hour lining them all up again for version two...
This is one of the reasons I strongly prefer text-based/command-line interfaces: they're always scriptable. In the worst case you'll just generate a bunch of commands that'd take a human forever to execute.
HTML is easy. CSS is hard. CSS is hard partly because it's a mess, but mostly because designing for the web is hard.
Normal human beings understand pages, in the papery sense of the word. They don't understand viewports. It takes an enormous leap of abstraction to reason about a document that could be any shape or size. Responsive design is a fundamentally unintuitive process. A lot of professional designers fail to understand this, even after years of designing for the web.
Documents are generally created and laid out for print and email distribution and often have very carefully laid out data tables, charts and page number referencing (as well as less important cosmetic formatting). Simply changing the file format isn't going to solve the accessibility problems and is going to create new formatting/compatibility issues, and and changing the workflow of every member of the civil service to require them to use an accessible HTML generation tool in place of word processors for anything that might be later made public isn't a trivial undertaking either. Said accessible HTML generation tool is probably going to want to change those nice HTML files back to PDF or Word files for restricted email distribution too...
I really like markdown but I doubt it's the answer to this.
These people aren't programmers, most of them will only have a loose grasp of what a file format is. What they need are tools that don't require a programming background.
