Kindle Format 8: Announcing HTML5 Support in Kindle Format 8(amazon.com)
amazon.com
Kindle Format 8: Announcing HTML5 Support in Kindle Format 8
http://www.amazon.com/gp/feature.html?docId=1000729511
34 comments
You might be right in abstract but in the real world technical decisions are often made by choosing the lesser of several evils.
Pure text is not good enough for many kinds of books - you need to at least support images (for cookbooks, children books, travel guides etc.), monospaced, bold, italic fonts (for programming books), vector graphics (for illustrations in technical books that will good at every dpi) etc.
There's no strictly ebook format that gives you that so you can either spend engineering resources trying to define and implement a new, non-trivial ebook format from scratch, with non-insignificant possibility of getting something wrong.
Or you can re-use the most wide spread document format in existence. A format that gives you everything you might ever want, has evolved over more than a decade, is tried and tested and works and is implemented on every platform imaginable and has open-source implementation that everyone can re-use.
HTML5 is the lesser of any other evil you can come up with as a new format for ebooks. Amazon made the right decision.
Pure text is not good enough for many kinds of books - you need to at least support images (for cookbooks, children books, travel guides etc.), monospaced, bold, italic fonts (for programming books), vector graphics (for illustrations in technical books that will good at every dpi) etc.
There's no strictly ebook format that gives you that so you can either spend engineering resources trying to define and implement a new, non-trivial ebook format from scratch, with non-insignificant possibility of getting something wrong.
Or you can re-use the most wide spread document format in existence. A format that gives you everything you might ever want, has evolved over more than a decade, is tried and tested and works and is implemented on every platform imaginable and has open-source implementation that everyone can re-use.
HTML5 is the lesser of any other evil you can come up with as a new format for ebooks. Amazon made the right decision.
Wait, doesn't PDF support all of the above? Why require HTML rendering? All sorts of issues arise since HTML is markup based and not layout based like PDF or ePub...
Have you tried reading a PDF on a kindle? It works. technically. But it's not pleasant.
Being in the Kindle conversion and formatting business, one of the advantages of having such a simple format was that self-published authors can create books that look just like those from major publishing houses. There's only so much you can do to make something fancy with the current Kindle format. With more capabilities, we'll likely see people try and do 'fancy' and end up with stuff that's actually not that great looking.
The wording of the text regarding 'older readers' is also a bit confusing. Will material created for KF8 be 'automatically translated'? Will the tools output two different formats? I'm curious to see the details.
I guess I'll need to order a Fire though, in order to keep up... I was a bit ambivalent, as I'm not wild about not having the Google stuff, and about the Android fork of an older version.
The good stuff: table support currently sucks, and the ability to do a bit more with the formatting will help with things like manuals or textbooks, that currently don't always work well on the Kindle.
I am worried, though, that for many people, it will be "enough rope to hang themselves with".
The wording of the text regarding 'older readers' is also a bit confusing. Will material created for KF8 be 'automatically translated'? Will the tools output two different formats? I'm curious to see the details.
I guess I'll need to order a Fire though, in order to keep up... I was a bit ambivalent, as I'm not wild about not having the Google stuff, and about the Android fork of an older version.
The good stuff: table support currently sucks, and the ability to do a bit more with the formatting will help with things like manuals or textbooks, that currently don't always work well on the Kindle.
I am worried, though, that for many people, it will be "enough rope to hang themselves with".
If all you need to code is traditional novels, then what we already have is fine.
If you want to code poetry, plays, research with footnotes, or anything else, then having access to more options is a wish come true. (Waste a few hours trying to hack any of the above into epub and you'll feel my pain.)
It's not like making this available makes it harder to code novels at all, so why complain?
If you want to code poetry, plays, research with footnotes, or anything else, then having access to more options is a wish come true. (Waste a few hours trying to hack any of the above into epub and you'll feel my pain.)
It's not like making this available makes it harder to code novels at all, so why complain?
Overall, I agree. The thing I like most about my e-ink nook is that the only thing it can do is reading, as opposed to the iPad, which always has the temptation to play a game, or check the web, or chase that ding which means new mail.
That said, I think that HTML5 capabilities can improve the reading experience if used properly. iPad-type tablets can get access to interactive experiences with technical books and comics, kindle-type tablets get improved typography and layout. Some publishers may abuse the tech, but there's still a very strong market for Just Plain Reading, so I don't think it will be too bad.
That said, I think that HTML5 capabilities can improve the reading experience if used properly. iPad-type tablets can get access to interactive experiences with technical books and comics, kindle-type tablets get improved typography and layout. Some publishers may abuse the tech, but there's still a very strong market for Just Plain Reading, so I don't think it will be too bad.
Well, the devices, future and present, want to do a lot of things that traditional typesetting can’t do. Having known page and type sizes is an assumption of print, but goes out the window when one wants to put a piece of content on different devices.
But I absolutely agree that the book is a valuable, time-tested format. We’ve learned a lot about readability. Conflating the goals of books and web pages would be a loss. NB, we still have radio.
But I absolutely agree that the book is a valuable, time-tested format. We’ve learned a lot about readability. Conflating the goals of books and web pages would be a loss. NB, we still have radio.
I think this is motivated more by Kindle Fire as a media consumption device than their e-ink readers. They make a compelling case with childrens books and comic books.
What about children books. What about innovative story telling formats. Magazines; old-school wired magazine could really do a number on kindle.
Yes, this is definitely needed. I have a book in an interlinear format that requires css floating elements for fluid display.
What is a book? Your kids will have a completely different notion of that than you...
At the moment I am still buying books for my son, and clumsy attempts at mimicking interactivity in paper based children's books seem to be all the rage. So even now books don't confine themselves to being just books.
At the moment I am still buying books for my son, and clumsy attempts at mimicking interactivity in paper based children's books seem to be all the rage. So even now books don't confine themselves to being just books.
Look at the many newspaper and magazine apps on the iPad. They often contain interactive content - videos, graphs you can blow up, slide shows, and so on. And I'd say they're better for that. If the Kindle Fire is going to compete with the iPad for those formats, it needs to provide a similar experience.
The rest of the comments here are suggesting that Kindle Format 8, in adding support for HTML5 and SVG, is adding a lot.
Well, you ain't seen nothin' yet!
On October 11, the IDPF membership unanimously voted to elevate EPUB 3.0 to a final IDPF Recommended Specification. And what's in EPUB 3.0?
XHTML 5, SVG 1.1, CSS 2.1 and 3, JavaScript, TrueType fonts, WOFF fonts, SSML/PLS/CSS3 Speech, SMIL 3, RDF vocabularies, MathML, and more...
Compared to EPUB 3.0 (parts of which are already supported by Apple's iBooks app), Kindle Format 8 is behind the times.
Well, you ain't seen nothin' yet!
On October 11, the IDPF membership unanimously voted to elevate EPUB 3.0 to a final IDPF Recommended Specification. And what's in EPUB 3.0?
XHTML 5, SVG 1.1, CSS 2.1 and 3, JavaScript, TrueType fonts, WOFF fonts, SSML/PLS/CSS3 Speech, SMIL 3, RDF vocabularies, MathML, and more...
Compared to EPUB 3.0 (parts of which are already supported by Apple's iBooks app), Kindle Format 8 is behind the times.
It'll take at least a year (maybe two) to ship EPUB3.0-ready devices. A large-ish, ongoing concern is with scripting. How would the security model for that look like?
Granted, Apple's recently gotten involved in the EPUB3 working group, and that may force some pressure on the group to ship. But the spec is rather vague in some areas, and I expect it to take some time to hash out.
I'd say that KF8 is equivalent to EPUB2. Maybe a wee bit better. But my fear is that it's good enough to warrant switching over from EPUB.
Granted, Apple's recently gotten involved in the EPUB3 working group, and that may force some pressure on the group to ship. But the spec is rather vague in some areas, and I expect it to take some time to hash out.
I'd say that KF8 is equivalent to EPUB2. Maybe a wee bit better. But my fear is that it's good enough to warrant switching over from EPUB.
Does KF8 support JavaScript? I don't see why allowing scripting in an e-reader app is any different from allowing it in a web browser app.
I also don't understand why you think it'll take so long to ship an EPUB3.0-ready device. The current iBooks app already allows for some embedded JavaScript (which only came with EPUB 3.0). Kobo says they'll have an e-reader device that supports EPUP 3.0 in the next 3-6 months: http://www.digitalbookworld.com/2011/five-tablet-trends-sign...
I also don't understand why you think it'll take so long to ship an EPUB3.0-ready device. The current iBooks app already allows for some embedded JavaScript (which only came with EPUB 3.0). Kobo says they'll have an e-reader device that supports EPUP 3.0 in the next 3-6 months: http://www.digitalbookworld.com/2011/five-tablet-trends-sign...
From the FAQ: "Will KF8 capabilities be available on all Kindle devices? A: Kindle Fire is the first Kindle device to support KF8 - in the coming months we will roll out KF8 to our latest generation Kindle e-ink devices as well as our free Kindle reading apps."
This implies that older Kindles won't get support for this. If that's true, Amazon's going to either get a bunch of pissed-off users or a shiny new format that nobody uses.
Part of what I love about the Kindle is that it's previously given off an aura of being above the "gotta update to the new model!" consumer frenzy that other portable electronics embody.
This implies that older Kindles won't get support for this. If that's true, Amazon's going to either get a bunch of pissed-off users or a shiny new format that nobody uses.
Part of what I love about the Kindle is that it's previously given off an aura of being above the "gotta update to the new model!" consumer frenzy that other portable electronics embody.
Q: Will I have to provide two versions of my titles going forward?
A: No. The upcoming updates to our Kindle Publishing Tools will take care of this for you. KindleGen 2 will convert your content so that it works on all Kindle devices and apps.
I think the biggest leap for Kindle was the Kindle 3 (aka "Keyboard Kindle"). If they support that, they should be fine. As far as I understand, the newer Kindles (touch, non-keyboard) use the same software and processor as the Kindle 3, so there is nothing preventing them from supporting it.
Besides, Kindle can render full blown websites and PDFs in its "experimental" browser, so some formatting enhancements in the Mobi parser should not be too much of a problem.
I hope.
Good thing Amazon is not Apple.
Besides, Kindle can render full blown websites and PDFs in its "experimental" browser, so some formatting enhancements in the Mobi parser should not be too much of a problem.
I hope.
Good thing Amazon is not Apple.
Older-Kindle users may be pissed off, but most of them have enough invested in the platform that hey aren't going anywhere. And the cheaper Kindle Basic (which should support the new format) is at least an olive branch on this front.
For Amazon, the more important thing to do is to address users of the reading apps, since those are the users who can more easily switch to an alternative (even if only for new purchases). And they're doing that.
For Amazon, the more important thing to do is to address users of the reading apps, since those are the users who can more easily switch to an alternative (even if only for new purchases). And they're doing that.
When Sony dumped its BroadBand eBook (BBeB) format, it transparently replaced books in that format with ePub for everyone who bought books in that other format. I think Amazon will do the same as books are moved to the new format. As Amazon keeps saying, your books exist on your bookshelf and can be re-downloaded any time. No big deal to switch the formats. For those with older Kindles, they could warn them the new format won't work. Since every Kindle has to be registered with Amazon, they know who has which generation of device.
I'm confused. Why would existing users be pissed? Their existing Kindles aren't going to stop working, new books will still be available for them, they just won't have some of the shiny new features, some of which may be of questionable value on their e-ink readers anyway.
Traditional typesetting is hard and not very amenable to reflow (as in, variable page sizes). The HTML/CSS world has worked a lot of this out.
(Though I am quite ignorant of the MOBI format that is being replaced.)
This also bodes well for taking web pages offline and onto dedicated reading devices, a la Instapaper.
(Though I am quite ignorant of the MOBI format that is being replaced.)
This also bodes well for taking web pages offline and onto dedicated reading devices, a la Instapaper.
Mobi is an unholy mess of HTML-inspired markup. I don't think anything else uses it, and it was designed to be rendered on incredibly constrained hardware that just doesn't exist anymore. It's OK to use a few megabytes of RAM to render a document now.
Using straight-up HTML5 lets them dump a bunch of code for proprietary rendering engines, I suspect. And it simplifies the Kindle fire and web-based / PC readers, where they can just embed an HTML renderer.
(Disclaimer: While I'm a former Amazon employee, I didn't work on or with Kindle. As a current Mozilla employee, I think HTML5 is pretty nice.).
Using straight-up HTML5 lets them dump a bunch of code for proprietary rendering engines, I suspect. And it simplifies the Kindle fire and web-based / PC readers, where they can just embed an HTML renderer.
(Disclaimer: While I'm a former Amazon employee, I didn't work on or with Kindle. As a current Mozilla employee, I think HTML5 is pretty nice.).
This is a surprising decision. I think most people were expecting Amazon to move away from Mobi but they probably expected Amazon to adopt EPUB especially as EPUB 3.0 is near release.
Epub would've been nice for us, but this makes more business sense.
The Kindle devices are cheap & low margin; Amazon's profit is from the content. They've got a customer mindshare majority (What's an ereader? Oh, you mean a Kindle), and a large author base. Why would they open up their devices to competing publishers?
The Kindle devices are cheap & low margin; Amazon's profit is from the content. They've got a customer mindshare majority (What's an ereader? Oh, you mean a Kindle), and a large author base. Why would they open up their devices to competing publishers?
As I mentioned in another comment here, on October 11, the IDPF membership unanimously voted to elevate EPUB 3.0 to a final IDPF Recommended Specification. Apple's iBooks (e.g. on the iPad) already supports some parts of EPUB 3.0 [1], and Kobo says they'll have an e-reader device that supports EPUP 3.0 in the next 3-6 months [2].
[1] http://www.robotmedia.net/2011/08/using-javascript-in-ibooks...
[2] http://www.digitalbookworld.com/2011/five-tablet-trends-sign...
[1] http://www.robotmedia.net/2011/08/using-javascript-in-ibooks...
[2] http://www.digitalbookworld.com/2011/five-tablet-trends-sign...
Really, only those engaging in magical thinking and unfamiliar with the way Amazon works expected Amazon to adopt ePub. I never did and said so repeatedly.
The list of supported HTML tags an CSS features is here (found inside article) http://www.amazon.com/gp/feature.html/ref=amb_link_357613442...
No scripting (JavaScript?) I suppose?
Do we really need HTML5 support? Isn't the purpose of Kindle to be a book?
Ok, I can grok colors. I might even go for interactive charts. But where does this stop? As a consumer, I would like my static content delivered in a separate device in a format approaching paper. My dynamic content I consume from a different device. One of the reasons is that various forms of content are more engaging (read addictive) than others, so by separating them I can budget my time. I don't think anything of spending 5 hours with a Kindle on the weekend because it's a book. If I spent that same time playing Angry Birds on my Android I'd know something is out of whack.
Does everything have to be an all-purpose display device? I kind of liked the Kindle because it was doing just the one thing. I'm not sure I understand why the format has to be updated so much.
EDIT: I'm also curious as to how this affects all the other readers out there. In E-Reader world, we live way back in the dark ages where every device is funky. Does this add more to the funkiness of trying to cross-deploy? Was there something so wrong with Keep it Simple, Stupid? It's text, for goodness sake. It's a book. I know I sound like grumpy-old-guy, but hell guys, ya think we could manage one format for displaying the world's oldest persistent communications format -- simple text -- without too many revisions?