CHchriswarbo·Jan 6, 2015
> Plenty of sites that were archived have their whole UI in flash, so for those sites the pages are pretty much empty pages without flash.
Nevertheless, it's still a smaller problem than, for example, broken links.
Firstly, the number of sites relying completely on Flash is relatively small, eg. compared to those which rely on hyperlinks (indexes or reading lists).
Second, there is less urgency to fix Flash sites compared to mitigating link rot: as long as the SWF content is archived, it can be converted/re-implemented at a later date. On the other hand, links are failing all the time, which requires immediate, persistent action (crawling).
Thirdly, there is a subjective argument about whether Flash sites are part of the Web or not, and hence whether this is much of a problem. At some point, an archive must draw a line and say "this is no
Read the rest
t Web content"; for example, archiving videos, or FTP sites, or Linux ISOs, or the content referred to by torrents or magnet links, or Windows EXEs, etc. It's an arguable choice to ignore Flash content completely. It's also an arguable choice to archive the Flash content but not care whether it runs. Of course it's also legitimate to want Flash to work seamlessly in the browser, but that's not the only position.
> I'm not aware of any JS-powered flash implementation
There are a few. A quick Google search reveals https://github.com/tobytailor/gordon/wiki and http://mozilla.github.io/shumway/ . At a stretch, Free Software, non-JS players like https://www.gnu.org/software/gnash/ , http://lightspark.github.io/ and http://swfdec.freedesktop.org/wiki/ could be ported to emscripten.
> or how that would solve anything since presumably that would come with all of the drawbacks that the non-JS powered flash implementations of today have (and that we are so keen on getting rid of).
Of course they have all the same problems (and more, since they're not fully compatible); but that's irrelevant. Backwards compatibility only requires that the stuff we used to do is still possible. If we send an un-screen-readable, un-keyboard-navigable mess of a Flash site to a perfectly compatible JS-based Flash implementation, we should hope to get an un-screen-readable, un-keyboard-navigable mess as well. As an analogy, it's a good idea to write an emulator for the Sinclair Spectrum, so that Spectrum games remain playable on new hardware. This does not mean that a) emulating a Spectrum game must produce modern-looking 3D, immersive, high-def, 24-bit colour graphics with surround sound; or b) that the existence of a Spectrum emulator should make the Spectrum a valid target platform for new commercial game development.