MobileRead Forums - View Single Post - First Editor's Draft of EPUB 3.1 now available

dgatwood · 02-12-2016, 01:40 AM

Here's my comment:

I absolutely agree with tofi86. This issue (https://github.com/IDPF/epub-revision/issues/633) and #644 are utterly baffling to me.

I’m assuming that when you say publishers are driving this, you mean **textbook** publishers—interactive book publishers. For those of us doing fiction, removing backwards compatibility would qualify as absolute brain damage, and that's not just my opinion; it seems to be the general consensus among a pretty good sized pool of independent publishers and content formatters.

As a publisher, I want to create content that will be readable on as wide a range of devices as possible. Web standards are deliberately built in such a way that they gracefully degrade on older devices that don’t support them. For this reason, I can take a modern HTML document and read it in Netscape Mosaic 0.9b3 or lynx 1.0 (early 1990s) as long as it doesn't require JavaScript. It might look like crap, but I can read it.

The reason web standards work the way that they do is to encourage adoption. I know that my content will gracefully degrade on older browsers, which means I can comfortably adopt bleeding edge CSS 3 features NOW. I'm doing this in the content for my EPUB books as well, introducing CSS 3 features like shape-outside on drop caps to produce spectacular typography on the tiny minority of reading platforms that support it, knowing that it won't break other readers, and that eventually users on other reading platforms will gain those capabilities as well.

Without that backwards compatibility, I wouldn’t be adopting those features for another five years, and probably more like ten. So in ten years, I’ll be able to adopt the EPUB 3.1 metadata format, when all of the early EPUB readers (many of which have been abandoned by their manufacturers) have all died from capacitor plague. In twelve years, I’ll be able to adopt EPUB 3.2. And so on. By the time features become usable, they'll be a decade behind the state of the art.

More importantly, Amazon et al won’t have this problem. They’ll be constantly pushing the limits of what the technology can do. So if our EPUB-formatted content has to lag behind by a decade to maintain backwards compatibility with existing readers, our Kindle-formatted content will be light years ahead at any given point in time. This will result in people saying things like “Get the Kindle version. The EPUB sucks.” Eventually, the entire EPUB format will wither on the vine.

If I had my way, these features wouldn't even be deprecated. They would be **optional**. Features shouldn't be deprecated until there is no longer any good reason for publishers to include them, which is certainly not the case yet by any stretch of the imagination. They should be deprecated in five or ten years, and removed several years after that.

02-12-2016, 01:40 AM	#2
dgatwood Curmudgeon Posts: 629 Karma: 1623086 Join Date: Jan 2012 Device: iPad, iPhone, Nook Simple Touch	Here's my comment: I absolutely agree with tofi86. This issue (https://github.com/IDPF/epub-revision/issues/633) and #644 are utterly baffling to me. I’m assuming that when you say publishers are driving this, you mean textbook publishers—interactive book publishers. For those of us doing fiction, removing backwards compatibility would qualify as absolute brain damage, and that's not just my opinion; it seems to be the general consensus among a pretty good sized pool of independent publishers and content formatters. As a publisher, I want to create content that will be readable on as wide a range of devices as possible. Web standards are deliberately built in such a way that they gracefully degrade on older devices that don’t support them. For this reason, I can take a modern HTML document and read it in Netscape Mosaic 0.9b3 or lynx 1.0 (early 1990s) as long as it doesn't require JavaScript. It might look like crap, but I can read it. The reason web standards work the way that they do is to encourage adoption. I know that my content will gracefully degrade on older browsers, which means I can comfortably adopt bleeding edge CSS 3 features NOW. I'm doing this in the content for my EPUB books as well, introducing CSS 3 features like shape-outside on drop caps to produce spectacular typography on the tiny minority of reading platforms that support it, knowing that it won't break other readers, and that eventually users on other reading platforms will gain those capabilities as well. Without that backwards compatibility, I wouldn’t be adopting those features for another five years, and probably more like ten. So in ten years, I’ll be able to adopt the EPUB 3.1 metadata format, when all of the early EPUB readers (many of which have been abandoned by their manufacturers) have all died from capacitor plague. In twelve years, I’ll be able to adopt EPUB 3.2. And so on. By the time features become usable, they'll be a decade behind the state of the art. More importantly, Amazon et al won’t have this problem. They’ll be constantly pushing the limits of what the technology can do. So if our EPUB-formatted content has to lag behind by a decade to maintain backwards compatibility with existing readers, our Kindle-formatted content will be light years ahead at any given point in time. This will result in people saying things like “Get the Kindle version. The EPUB sucks.” Eventually, the entire EPUB format will wither on the vine. If I had my way, these features wouldn't even be deprecated. They would be optional. Features shouldn't be deprecated until there is no longer any good reason for publishers to include them, which is certainly not the case yet by any stretch of the imagination. They should be deprecated in five or ten years, and removed several years after that.