Comment by hunter2_ 16 hours ago
I agree with no JS, but why PDF over HTML? Hard-wrapping for letter-sized paper (ok, a PDF doesn't need to be letter-sized, but most menus are approximately that) with crapshoot reflow options for soft-wrapping in certain viewer apps is pretty dicey on a phone, mitigated only slightly by rotating the phone sideways.
The only benefit I can think of is if it leads to more frequent updates by the restaurant, due to limited skillset.
index.pdf won't tend to play nicely with screen readers and also sucks for people on crappy mobile networks, so it's a minor inconvenience for some, and straight up unusable for others
> index.pdf won't tend to play nicely with screen readers
The horrible Wix sites most restaurants end up using are likely less accessible than a PDF. The Adobe PDF reader can reflow text.
> also sucks for people on crappy mobile networks
The average wysiwyg site builder produces bundles that are an order of magnitude larger than a PDF menu. Also, the PDF is easier to cache correctly and can be easily saved for offline access.
But you can easily serve a desktop version or a small screen version.
I vastly prefer looking at a PDF menu over an HTML one nearly all the time. PDFs are usually nicely formatted, and I don’t mind zooming and panning to see everything. HTML is frequently terribly formatted, interspersed with ads, slow, etc
The complexity between the modern web and a pdf is marginal. PDFs do get printed for menus. Editing a PDF and uploading it to the site, integrating prices and syncing between the site, online ordering, PDF menus is just part of the business. There are lots of platforms that help with this such as Slice.
If the restaurant doesn't have anything besides a menu, /index.pdf is fine—no web design required; reuse the menu they're printing anyway.
The trade-off is that they'll have to pinch/zoom if they have a small display. It's a minor inconvenience to make the exact information they want available instantly.