Fragment identifiers

[DiapDealer]

Originally Posted by mrmikel

but for epub3, the device manufacturers aren't even trying, with Apple and Kindle not complying with anything.

In all fairness, Amazon has no reason to comply with any epub specs. They neither sell them in their store nor support the format on their devices (or in their apps). They will happily accept epubs (2 or 3) as valid source-code (as well as various other html/css/oebps representations of content) for compiled Kindlebooks, though.

They simply have no dog in the epub-spec-compliance hunt in my opinion. That's all on Kobo/Nook/iBooks/Sony/Adobe/etc's heads.

[mrmikel]

No judgement implied, just a long sigh.

[dgatwood]

Originally Posted by DiapDealer

In all fairness, Amazon has no reason to comply with any epub specs. They neither sell them in their store nor support the format on their devices (or in their apps). They will happily accept epubs (2 or 3) as valid source-code (as well as various other html/css/oebps representations of content) for compiled Kindlebooks, though.

They simply have no dog in the epub-spec-compliance hunt in my opinion. That's all on Kobo/Nook/iBooks/Sony/Adobe/etc's heads.

As for me, I'd be happy if they all just complied with the HTML specification.... *sigh*

[DaleDe]

Originally Posted by DiapDealer

In all fairness, Amazon has no reason to comply with any epub specs. They neither sell them in their store nor support the format on their devices (or in their apps). They will happily accept epubs (2 or 3) as valid source-code (as well as various other html/css/oebps representations of content) for compiled Kindlebooks, though.

They simply have no dog in the epub-spec-compliance hunt in my opinion. That's all on Kobo/Nook/iBooks/Sony/Adobe/etc's heads.

I would disagree. Amazon accepts ePub as the source file for conversion and thus have a stake in the standard. They even define the specific specifications that they support. It is exactly like ePub version 1 (Called OEB in our wiki). All of the players following that standard used it only for the source and then compiled it into the reading file. Amazon has done exactly the same thing for KF8. It is simply a binary compiled form for an ePub source file. To say that they have no stake is like saying that someone who releases a executable written in "C" has no stake in the "C" standard.

Having said that Amazon is also tinkering with some sort of JSON standard as well for iOS version of its reader.

Dale

[DiapDealer]

We'll have to agree to disagree then.

I've never been fully onboard with the "KF8 is just a compiled ePub" oversimplification. In a very loose, layman's overview ... perhaps. But that's beside the point. The truth is: the IDPF could disband tomorrow and Amazon would just take on the responsibility of publishing their own kindlebook source code specifications. After all ... a KF8 ebook can still be made from nothing other than a single html file. That's why the "executable written in 'C' has no stake in the 'C' standard" allegory isn't all that apt. You don't need an epub to create a KF8. The InDesign plugin renders InDesign documents into kindlebook source code.

Sure, they have an interest in ePub specifications, but they don't really care if there's ever any overwhelming compliance in how all those epub specs are interpreted by developers creating epub rendering engines. Why would they?

So yes ... they have a stake in the specs themselves I suppose. Just no stake (or interest) in how those specs are interpreted (complied with). Their ebooks will never be read by all those devices/apps that can't agree on how the epub specs should be interpreted.