My thought has been more like, "I guess I've never really understood the need for ePub when HTML is now a standard." … which is exactly what this announcement is about.
Ideally, ePub would be "reflowable HTML plus baked-in things you would obviously want in a book made dead simple for author-editor-publisher workflows that will never involve a programmer in a million years". Proper footnotes that appear on the same page as the thing they're footnoting, for example.
In practice though this is still a shitshow even in ePub 3, 99% of publisher just ship a pile of endnotes, and consequently certain authors like Terry Pratchett are a god-awful experience in ebook format. Jumping back and forth every 30 seconds sucks.
There are work-around that can be done with JS or certain reader-specific markup you can use for iBooks to at least get pop up footnotes, but most publishing houses don't have the technical knowhow or desire to invest that much time in doing the right thing. There needs to be dedicated markup and a better standard for how readers should treat its display whenever possible.
A real failure of the standardization committee, and it will likely only get worse with a group that cares even less about books specifically. The standard continues to be driven by people more interested in gee-whiz features than solving longstanding problems in replicating table-stakes features of print.
Readers complain that ebooks cost too much, and then readers complain that publishers don't want to spend money on technical stuff.
But some of the problem is that there's not a lot of payoff for technical development, because only some platforms will support it. The Kindle doesn't handle Javascript or math at all, has very poor support for tables, SVG art, and video. So there's half your market gone right there.
> Readers complain that ebooks cost too much, and then readers complain that publishers don't want to spend money on technical stuff.
To be clear, I'm complaining that the standard overcomplicated certain desirable feature to the point where publishers would have to spend money on technical stuff, when they shouldn't have to.
I fully get why publishers don't want to have to engage in fiddly, expensive bespoke development per-title.
One thing is packaging: there's a desire to have a single file to ship to users to put on their devices instead of a whole folder (and changing that at this point is probably too painful to be worth it), and then you need to address how to deal with addressing (in URLs) other things within the package.
Of course, being packaged also make it much easier to apply DRM (and, perhaps thankfully, means we don't actually need to address DRMing of HTML content directly which helps fight against it being in browsers).
Well, that was the plan, and it was largely even true for EPUB 1 and EPUB 2.
EPUB 3 wound up being so baroque and overblown that there's still not even one fully-compliant implementation, more than 5 years after the standard was published. They had to back off some time ago and bless efforts that implemented only subsets of the full spec, but the damage had been done.
It's the second-system effect from hell (even though it was technically the third system).
