No one should need JS to see the soups when that could be handled perfectly fine with CSS. I wish restaurants would just make their homepage a PDF of the menu.
The only benefit I can think of is if it leads to more frequent updates by the restaurant, due to limited skillset.
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.
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.
Curious, I haven't tried it.
You can put ads into terribly formatted PDFs too
No one does either of those, IRL.
It's not even about blind people. People with ADHD or dyslexia use assistive technology, which frequently makes an absolute horlicks of interpreting PDF. It's one of the reasons I'm trying to move a lot of documentation at work away from PDF and onto just straight HTML.
Plain old HTML, with thin CSS on it to make it not be black-and-white Times New Roman. Kicking it oldschool.
Wait for 2 more iOS redesigns and everyone will use assistive technology on Apple devices :)
Using an LLM to translate the visible part of a PDF on a mobile... seems like the worst possible solution to the problem.
For example: if there's a dish name with a 2 line description below it and some allergy symbols below that, in HTML you can imagine the document structure that produces that. In PDF terms that might be 4 separate objects and, in particular, the eyes can see the two lines are adjacent so they fit together but the document structure doesn't really represent it taht way, necessarily.
This might also not work with translation because the lines are set for the size of the text they contain. Same for resizing the font.
Put another waay, PDF should be viewed as a typeset and layout format, not a document format.
[0] https://github.com/Local-Cafe/localcafe-lite?tab=readme-ov-f...
- https://astro.build/themes/details/astropie/
- https://astro.build/themes/details/astrorante/
- https://astro.build/themes/details/tastyyy-restaurant-websit...
Netlify is a great company that I'll always support.
Making a website's basic functionality work without JS isn't just for the random users who switch off their browser's JS runtime.
It's also for the people who have a random network dropout or slowdown on a random file (in this case a JS file).
Does that really apply when the javascript is only ~2kb?
That is what's happening any time you've seen a website that randomly decides to load without styles, or with a missing image.
The good thing is that it's very apparent when that happens and you can just reload the page.
But it's not immediately obvious when it happens with a JS file.
That's half the reason why you shouldn't re-implement css features in a js file. (the other half is performance)
> the javascript is only ~2kb?
It can be even 200Mb if it's not loaded properly and now a website doesn't even function.
When CSS doesn't load, it's immediately apparent and the user knows they need to reload the page.
It doesn't have anything to do with progressive enhancement.
You're saying that when the enhancement doesn't work, it's desirable that "it's immediately apparent and the user knows they need to reload the page". That's the opposite of what progressive enhancement people normally argue for.
In my area most restaurants have no website.
If they have a website it's often very hard to find their opening hours. Under 'contact'? Nope! At the footer? Nay! Maybe somewhere hidden in the menu PDF? With luck... Outside their homepage at google maps? Maybe. On their Tripadvisor page? Hahaha! Funny! Not.
Actually, nobody should need an XML parser to see the soups either.
/s