4 ms·

If you had to guess, what will be the next content format to become inaccessible due to a changing software landscape? Is there anything we can do now to work t

by yosito 5y ago

If you had to guess, what will be the next content format to become inaccessible due to a changing software landscape? Is there anything we can do now to work to preserve the content in that format?

paulgb 5y ago
I wonder about some of the highly-interactive pieces that newsrooms put out. Things like this: https://www.nytimes.com/interactive/2020/10/12/style/from-here.html https://www.nytimes.com/interactive/2020/10/12/style/from-he...
sp332 5y ago
Did Chrome ever allow users to enable autoplaying audio?
- throw_m239339 5y ago
  > Did Chrome ever allow users to enable autoplaying audio? Curiously, Chrome disallow users to disable autoplaying videos...
the8472 5y ago
Multiplayer games where the game servers are never released?
- oakesm9 5y ago
  This has already happened many times. One of the early examples is Habitat from 1986. There’s a video about trying to save it here https://youtu.be/kRAUO3v-Xkc?t=812 https://youtu.be/kRAUO3v-Xkc?t=812
jraph 5y ago
I'd answer the opposite question: what could increase the chances of a document to last? - The document should be archived to a place where people actively manage the archives. Servers and domain names may vanish, long term backups are incredibly hard, we need something robust managed by dedicated experts. - use pure text, encoded in ascii UTF-something. These encodings are widespread and unlikely to vanish, or many things would be inaccessible anyway. - use simple HTML, with medias (images, videos, sounds) embedded in a standard way using img, audio, video, possibly object tags. HTML is widespread, and it's still relatively easy to build a web engine that will render this into an exploitable result. At worst, one can skim through an HTML code or search for keywords in it, even if it's not perfect. - using the XHTML syntax might help: it's way easier to re-build an XML parser than a complete HTML5 parser with all the weird rules - The document should render legibly with JavaScript disabled so we don't require our lineage to maintain a JavaScript engine or run some sort of emulator with outdated software. - The document should render legibly with CSS disabled. At worst, building a simple HTML engine will probably still be easy to do. - The document should render legibly without any custom font that might not be exploitable in the future - If you can't help requiring CSS, use simple CSS directives. This may increase the chances for our lineage to be able to rebuild a simple web engine with just the necessary stuff to render the old documents; - if you can't help using Javascript, all the important resources should at least load at page load (except for images / videos / medias if they are lazily loaded using the lazy HTML attribute or something of the sort). It will probably ease archival a lot. It should not be necessary to run your code to figure out how to retrieve all the document's dependencies. - anything animated by custom code is more likely to be inaccessible in the future. Sometimes it's necessary, but the document without those parts may still be valuable for future historians. It may help describing those parts in the text of the document so at least historians will be able to know that something is missing and what. - don't use anything relying on a closed specification. Ideally use widespread standards only. Open but not widespread standard will probably not be re-implemented by historians. - if HTML or something similar like DocBook is not used, an easy to re-implement subset of PDF is probably ok. Many things are only available in PDF so historians will probably have to find a way to manage PDFs. PS might be ok too. - text in Unicode is probably way better than text embedded in images or drawn as shapes in vector formats. In the future, people might not use the same alphabets as the ones we are using today, recognizing our letters and signs will be probably hard for them. At least Unicode would provide them a way to render our letters in a standard, unique, easy to manage way. CDNs are another aspect to consider: they can vanish, losing dependencies of your document. The document should be archived before this happens. The problem with complex Javascript code: as long as web engines are well maintained, we are probably good. We can hope that backward compatibility will be kelp, but the more the document uses complex / advanced features, the more it is likely to use an API that will be deprecated and then removed. It has already happened. Try using -moz-border-radius today for instance. But even with web maintained engines, complex code will probably make it harder to handle the document for archival and consulting (one thing an historian may want to do is search for keywords in an archive. But if the content appears only when some complex code is executed, it may be difficult to manage). We also cannot assume that web engines as we know them today are going to be maintained forever. A revolution might happen. Applications could move from the web to another runtime, making the maintenance of a browser engine expensive and overkill. A new format adapted to documents could appear. Or a new way of producing, transmitting and viewing content. Unfortunately, it's very hard and costly to implement a Javascript engine with all the features provided by the web engine + a full web engine with all the whole CSS feature set from scratch. We'd better make the life of our future historian easier by not over using the features we have today to write documents.
- spicybright 5y ago
  The above may help, it's not realistic for the vast majority to publishers to follow the above. What do you think of using virtual machines in some capacity?
  - jraph 5y ago
    VMs suppose you still have the OS images and applications at hand, and make it more difficult to mass-handle all this information in a convenient / workable way. They require powerful machines, and, indeed, advanced emulators. But I'd argue that this is realistic for most publisher. See for example bbc.co.uk or theguardian.com. Their articles render well even in a terminal-based browser without CSS like w3m. For me this shows that this is realistic. What special need would require a publisher to break this? You may still use complex CSS/HTML/JavaScript, only the page should render well without the complexity. Graceful degradation / progressive enhancement are okay. I actually browse the Web with JS disabled by default and many things work actually well. Problematic pages are documents that are written like applications with a frontend framework, leading to blank pages. Or pages that have a strange behavior like an endless redirection/refresh when Javascript is disabled. Yes, I've seen that. Those pages are probably difficult to archive and will probably be harder to handle in the future.
forinti 5y ago
PDFs worry me because they are not what users think they are and few people bother to make them PDF/A.
deleted 5y ago
[deleted]

by yosito 5y ago

If you had to guess, what will be the next content format to become inaccessible due to a changing software landscape? Is there anything we can do now to work to preserve the content in that format?

paulgb 5y ago

I wonder about some of the highly-interactive pieces that newsrooms put out. Things like this: https://www.nytimes.com/interactive/2020/10/12/style/from-here.html https://www.nytimes.com/interactive/2020/10/12/style/from-he...

sp332 5y ago

Did Chrome ever allow users to enable autoplaying audio?

throw_m239339 5y ago
> Did Chrome ever allow users to enable autoplaying audio? Curiously, Chrome disallow users to disable autoplaying videos...

the8472 5y ago

Multiplayer games where the game servers are never released?

oakesm9 5y ago
This has already happened many times. One of the early examples is Habitat from 1986. There’s a video about trying to save it here https://youtu.be/kRAUO3v-Xkc?t=812 https://youtu.be/kRAUO3v-Xkc?t=812

jraph 5y ago

I'd answer the opposite question: what could increase the chances of a document to last? - The document should be archived to a place where people actively manage the archives. Servers and domain names may vanish, long term backups are incredibly hard, we need something robust managed by dedicated experts. - use pure text, encoded in ascii UTF-something. These encodings are widespread and unlikely to vanish, or many things would be inaccessible anyway. - use simple HTML, with medias (images, videos, sounds) embedded in a standard way using img, audio, video, possibly object tags. HTML is widespread, and it's still relatively easy to build a web engine that will render this into an exploitable result. At worst, one can skim through an HTML code or search for keywords in it, even if it's not perfect. - using the XHTML syntax might help: it's way easier to re-build an XML parser than a complete HTML5 parser with all the weird rules - The document should render legibly with JavaScript disabled so we don't require our lineage to maintain a JavaScript engine or run some sort of emulator with outdated software. - The document should render legibly with CSS disabled. At worst, building a simple HTML engine will probably still be easy to do. - The document should render legibly without any custom font that might not be exploitable in the future - If you can't help requiring CSS, use simple CSS directives. This may increase the chances for our lineage to be able to rebuild a simple web engine with just the necessary stuff to render the old documents; - if you can't help using Javascript, all the important resources should at least load at page load (except for images / videos / medias if they are lazily loaded using the lazy HTML attribute or something of the sort). It will probably ease archival a lot. It should not be necessary to run your code to figure out how to retrieve all the document's dependencies. - anything animated by custom code is more likely to be inaccessible in the future. Sometimes it's necessary, but the document without those parts may still be valuable for future historians. It may help describing those parts in the text of the document so at least historians will be able to know that something is missing and what. - don't use anything relying on a closed specification. Ideally use widespread standards only. Open but not widespread standard will probably not be re-implemented by historians. - if HTML or something similar like DocBook is not used, an easy to re-implement subset of PDF is probably ok. Many things are only available in PDF so historians will probably have to find a way to manage PDFs. PS might be ok too. - text in Unicode is probably way better than text embedded in images or drawn as shapes in vector formats. In the future, people might not use the same alphabets as the ones we are using today, recognizing our letters and signs will be probably hard for them. At least Unicode would provide them a way to render our letters in a standard, unique, easy to manage way. CDNs are another aspect to consider: they can vanish, losing dependencies of your document. The document should be archived before this happens. The problem with complex Javascript code: as long as web engines are well maintained, we are probably good. We can hope that backward compatibility will be kelp, but the more the document uses complex / advanced features, the more it is likely to use an API that will be deprecated and then removed. It has already happened. Try using -moz-border-radius today for instance. But even with web maintained engines, complex code will probably make it harder to handle the document for archival and consulting (one thing an historian may want to do is search for keywords in an archive. But if the content appears only when some complex code is executed, it may be difficult to manage). We also cannot assume that web engines as we know them today are going to be maintained forever. A revolution might happen. Applications could move from the web to another runtime, making the maintenance of a browser engine expensive and overkill. A new format adapted to documents could appear. Or a new way of producing, transmitting and viewing content. Unfortunately, it's very hard and costly to implement a Javascript engine with all the features provided by the web engine + a full web engine with all the whole CSS feature set from scratch. We'd better make the life of our future historian easier by not over using the features we have today to write documents.

spicybright 5y ago
The above may help, it's not realistic for the vast majority to publishers to follow the above. What do you think of using virtual machines in some capacity?
- jraph 5y ago
  VMs suppose you still have the OS images and applications at hand, and make it more difficult to mass-handle all this information in a convenient / workable way. They require powerful machines, and, indeed, advanced emulators. But I'd argue that this is realistic for most publisher. See for example bbc.co.uk or theguardian.com. Their articles render well even in a terminal-based browser without CSS like w3m. For me this shows that this is realistic. What special need would require a publisher to break this? You may still use complex CSS/HTML/JavaScript, only the page should render well without the complexity. Graceful degradation / progressive enhancement are okay. I actually browse the Web with JS disabled by default and many things work actually well. Problematic pages are documents that are written like applications with a frontend framework, leading to blank pages. Or pages that have a strange behavior like an endless redirection/refresh when Javascript is disabled. Yes, I've seen that. Those pages are probably difficult to archive and will probably be harder to handle in the future.

forinti 5y ago

PDFs worry me because they are not what users think they are and few people bother to make them PDF/A.

deleted 5y ago

[deleted]