You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi everyone, thanks for all your work on this. Really excited about getting to use this in teaching.
If it's OK to post a wishlist item: What should happen in JS-free environments? (Maybe humans, more likely spiders and scrapers). Currently, if you enable IIIF derivatives, loading a wax site with JS disabled means you get an image-free web page. (At least in my cursory testing?) And Internet Archive can't cache the image portion of a fancier wax site, while, say, an Omeka page will get fully archived.
One option would be to create the non-IIIF images in the IIIF task as well, load <img src="static_loc.jpg"> elements in the relevant slot, and then immediately delete those images with a little piece of Javascript.
Problems:
It's a pain to execute for a pretty esoteric reward. There are more important things to do.
It seems like it's hard to cancel the in-process image request here, and so you might be sending both the static img and the IIIF manifest to the vast majority of people who don't disable JS. That's rude to phones and not minimal. Depending on the other things being transferred, it might be possible to call window.stop and then restart everything except the img src calls, but that increases the pain on point
Doesn't totally solve the Internet Archive problem, since in browser the JS runs but the spider didn't cache. If the IIIF path fails, it might be worth doing something in JS to restore the img src back into its slot.
Makes the derivative-loading sites slightly larger, probably.
The text was updated successfully, but these errors were encountered:
Linked a pull request with the simplest possible version of this. If OSD is enabled, it tries to load both sources, with display:none on the OSD one; on successfully fetching an IIIF manifest, it switches CSS display to make that the visible one. Not sure if this meets all the cases where OSD is used.
Alternative approach would be to build a parallel site without javascript, auto-redirect to that site, and then kill the redirect with javascript. Slightly more expensive on the non-JS pages; I don't know how it plays with internet Archive.
Hi everyone, thanks for all your work on this. Really excited about getting to use this in teaching.
If it's OK to post a wishlist item: What should happen in JS-free environments? (Maybe humans, more likely spiders and scrapers). Currently, if you enable IIIF derivatives, loading a wax site with JS disabled means you get an image-free web page. (At least in my cursory testing?) And Internet Archive can't cache the image portion of a fancier wax site, while, say, an Omeka page will get fully archived.
One option would be to create the non-IIIF images in the IIIF task as well, load
<img src="static_loc.jpg">
elements in the relevant slot, and then immediately delete those images with a little piece of Javascript.Problems:
window.stop
and then restart everything except the img src calls, but that increases the pain on pointThe text was updated successfully, but these errors were encountered: