Your approach to sandboxing browser PDF rendering is to just not do it..?
You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application.
I can't see how this would be pragmatic or productive, or maybe it's not meant to be.
> You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.
I mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.
People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things.
I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent.
The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge.
Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
From personal experience browsing websites, especially sites that display catalogues, manuals, or specifications, a whole lot of them produce PDF content and then go out of their way to render it with JavaScript. The worst use horribly performing systems that make consuming the content miserable. Better commercial systems are a step up (Issuu is a whole company that seems to be developed around doing this). Even better ones use PDF.js. But the best ones... drumroll please... just link to the PDF as Content-Disposition: inline. If users want to save it, then they click save. And this is great -- you want your users to have the easiest time possible interacting with your marketing material.
> fill forms in the browser (where their authenticated context resides)
I have never, in my entire life, seen a web form implemented as a PDF where this was anything other than miserable. Use a form, thank you very much. The less SPA magic and the fewer intermediate submit buttons, the better. (Maybe, if the actual goal is for a user to fill out a form and print the result, offer PDF.js to users on Windows who might otherwise be stuck with Acrobat. I distinctly remember Acrobat being the best PDF-form-filling software maybe 20 years ago, but Acrobat has gotten, if anything, worse, and basically every other package out there runs circles around it.)
They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise.
You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it.
Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction.
And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
> They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise.
> Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction.
Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued.
It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign.
> I'm going to discontinue this conversation though.
Sometimes the PDF itself has to be signed. No conversion from forms. Also, tons of people would rather not have to download the PDF and email it, especially if they are on mobile. There's almost 0 usability advantage to doing that, because Adobe acrobat or whatever other pdf reader that users have and lets them sign stuff is often worse than even a JavaScript implementation. I'd much rather just sign on the browser than send an email back and then... wait or not have an immediate confirmation, or just having to deal with anything else than just pressing next.
I'm sure a lot of people here will disagree but most websites don't target the minority that prefers an email based workflow.
Or they could just implement full support for PDF. It had forms from the get go in the 90's. There is zero need to implement the functionality with JS.
You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application.
I can't see how this would be pragmatic or productive, or maybe it's not meant to be.