Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice. As the grandparent points out, Microsoft values backwards compatibility. If you value that too, buy Microsoft.
I'm not talking about software, I'm talking about information. Information shouldn't have an expiration date. Here's a webpage from 1994: http://www.lysator.liu.se/pinball/expo/ Surely you wouldn't prefer a world where the blog you wrote 4 years ago can't be viewed on a new computer?
So yes, under some circumstances, old formats are deprecated - even on the web. The world is better for it, but it still sucks for those who need that old stuff and are unable to move it forward.
Also worth pointing out it's much easier to display old formats than it is to make them editable.
IMG tags with unquoted SRC attributes, and unquoted ALIGN attribute
BASE tag with default attribute - tag is: <base="http://www.lysator.liu.se/pinball/expo/"> but should be <base href="http://www.lysator.liu.se/pinball/expo/">
UL tags with no LI tags
It's a good thing that webpage didn't use the <blink> element.
A counter argument to that, is I'm not sure if I want to live in a world where parsing an HTML document takes over 1,000,000 lines of unparallelizable C. You are sweeping a huge requirement that makes the rendering of that page possible in 2014. Ultimately it takes software to render that information, and the software that does render that, may have an expiration date.
How about if we're talking a blog I wrote 20 years ago, vs. some really nice improvement in modern software?
Backwards compatibility is great, and ideally no data would ever be lost to bitrot, but backwards compatibility always has a cost. I'm not unilaterally willing to pay that cost.
Is it really so difficult to just not break a feature that was present in the last version of the software?
At worst (like in the case of iWork 13 which probably is completely new code), you get one programmer to spend a few days writing a converter which reuses most of the old code.
This is not a useful statement. If you convert the "should" to a "shall", and try to design a system around that requirement alone, it would prove very hard. Even designing a clock around that requirement is very hard (http://longnow.org/clock/).
If you back off from the "shall", then you are in the standard world of engineering tradeoffs, which is where you started.
What features do you want to give up for "eternal"?
I'm the developer who build their related Long Bets project (http://longbets.org/) and I think "data should be eternal" is a perfectly reasonable standard. That was certainly my goal in designing Long Bets.
If you start with that as a principle, I don't think it imposes particularly large engineering burdens, especially if you accept some potential degradation as a consequence.
For example here, instead of a "fuck you" dialog box, they could have imported the core of a presentation: text and images positioned on a sequence of frames.
An analogy is HTML. It's basically zero engineering effort to just suck the text out of a page. It is only modestly more effort to pull out some of the semantic markup, like headings, lists, and emphasis. And that's the part that really hurts to lose, not which precise shade of blue you used in your footer text.
This can be said for all sorts of things, from the Commodore 64 to Keynote. If you want to be able to access the data on an NES cartridge you are going to need special hardware and software. Yes the ROMS are available now online, but that's only because someone with the hardware and software made it available to others.
This is the nature of proprietary formats.
Indeed. When you choose to save your work in a not-public format, you are decidîng not to care about its lifespan: complaining later is just useless, unfortunately.