For the record, it was the day before that when I tried to submit HTML5, and Al Haines refused it, just as I said PG refuses HTML5 -- so I don't see where the controvery is? And since, as I said previously, the new Amazon tools expect HTML5, so that won't be helping us submitters any. It presumably could help Marcello, who can target HTML5 as the output of his HTML Epubmaker rewrite tools, where hopefully he can now turn off some of the other rewriting "workarounds" he has been doing to target MOBI. The new tools would make it a lot easier for submitters who are writing (sensible) HTML intended to actually target EPUB and MOBI to have a better chance of "just" targeting EPUB and then getting MOBI "for free." Or is Marcello going to insist on staying with the old crusty version of kindlegen as well? If someone, like I did, now downgrades their HTML5 to 4 in order to get PG to accept it, then what? Do "we"/I keep a copy of my HTML5 version in hand, and then do a hypothetical merge on the then-current PG version when PG gets around to it to actually accepting HTML5? Or presumably PG will refuse to do that, and continue their current policy of defending to the death old crusty versions of HTML of otherwise great books which, because they are old crusty versions, really don't do anyone any good any more? And presumably this means the "real" development path for people who actually care about creating HTML that real people can read on real machines is that we get to write in HTML5, try that HTML5 out on real machines using EPUB and MOBI compilers (like kindlegen) and then once we have working HTML5 then we get to hack it back down to 4 to submit it to PG, and then we get to hack it back down yet again, to turn it into PG txt72. ??? Al> For the record, it was only this afternoon that it was made quite clear to him, by myself and Greg Newby, that PG will probably eventually accept HTML5 files, but not, repeat Not, repeat NOT (my emphasis), until it becomes a W3C Recommendation (it's currently a W3C Working Draft, subject to change), and the W3C validator accepts HTML5 files without errors or warnings. [The W3C issued warnings about old browser compatibility because I included a BOM as a file transfer courtesy to PG, since I have no idea what kind of computer nor tools they process their files with. I would have thought that PG would have just stripped the BOM if they don't like BOMs] What Jim Said>As input format they accept HTML5 and CSS3, not that that will help us submitters because PG refuses to accept HTML5. Hopefully PG will at least pick up the new version of kindlegen so they can turn back off some of the Marcello file rewriting.

But what is the internal format for the Kindle and MOBI? Does the Kindle or

the Fire support /any/ of the new features of HTML 5? What I think "we" are talking about is heading towards XHMTL5, which is compatible with KF8 (Mobi Version 8) and which will be compatible with EPUB3. By writing code that the tools can accept "directly" and which display correctly on current browsers, then we can reduce the amount of rewriting that Marcello has to do. Or that other tools have to do. And hopefully start heading in a direction where the EPUB and the MOBI that PG posts renders much more similar to how the HTML that PG posts renders, with the PG EPUB and the PG MOBI showing much less frequent "broken parts" -- which happens more often than not nowadays. New HTML5 Elements which seem useful to the PG cause which Amazon says the new Kindlegen (and KFire) supports: wbr section article aside hgroup header footer figure figcaption mark I haven't done an "all points test" yet on the new kindlegen to see how it actually implements this stuff. See http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000729901

We all know that internally the Kindle supports only a slight variation of HTML 3.2.

Not sure what "we all know." Are you saying Kindle Fire is only internally HTML 3.2? Are you saying KF8 is only internally HTML 3.2? Agreed that the new kindlegen *does not* seem to "magically" fix all the limitations of the older generations of Kindle. Most notably the paragraph top-margin/bottom-margin problem which keeps killing so many of the PG MOBI files remains on older Kindles even using the new kindlegen. See also: http://www.w3.org/TR/html5-diff/

Lee>We know that the pre-Fire Kindle reader does not support HTML 4 tags, or CSS. Sorry, but I don't know exactly what your prc2html program does. "We" know from mobi_unpack.py and copious net conversations that kf8 actually contains two separate file formats in one: a copy of the oldy moldy "mobi7" file format targeting "pre-current-generation" Kindles [*not* pre-Fire Kindles] and a "mobi8" file format targeting "current-generation" Kindles. Amazon's cloud server supposedly cuts this down on-the-fly and is smart enough to only send that part which is needed by a particular Kindle -- if the kf8 file gets served by Amazon from Amazon. [Don't know what happens if the kf8 gets served *through* Amazon by say a PG customer sending a hypothetical PG kf8 *through* Amazon using say the Amazon "Send to Kindle" desktop program.] Now of the "current-generation" Kindles the reality is only Kindle Fire *currently* has the software to render "mobi8" but Amazon claims they are busily churning away trying to get the updates out to allow "current-generation" Kindles to also render "mobi8" -- but Amazon has not been explicitly explicit about exactly what Kindle models they mean when they say "current-generation" Kindles. Does your prc2html software successfully extract *both* these file formats, or only the "mobi7" part? Now one problem for PG I would think with the "two, two, two formats in one" kf8 packing is that the currently already bloated mobi7 format (assuming one turns off compression, which I think is what PG is currently doing) becomes an even more bloated up (uncompressed) kf8.

Yes, KindleGen doesn't fix the limitations of earlier software, and indeed cannot. It /can/ modify/convert the input in such a way that older software can deal with it, but KindleGen can't make a silk purse out of a sow's ear.

Well, without intended insult but just stating the reality, that's what on some level Marcello's rewrite software attempts to do. There are at least three sources of cruftiness here: 1) The oldy-moldy mobi7 format 2) The oldy-moldy "html" files on PG that PG in practice makes impossible to update -- even for their most popular books 3) Current html writing practice of many people and groups submitting html to PG that is continuing to be written in a needlessly thoughtless way that prevents that html from displaying well on a large portion of PG's customers' devices even though they would only have to change a couple statements in their CSS slightly to make the situation much much better.