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.