ePub limitations, good practices and safe bets.

[Turtle91]

Originally Posted by JSWolf

Given that most (if not all) reading systems won't handle scripting, it's a waste of time and effort to put scripts in ePub 2 eBooks.

So much for my idea of making a "Choose Your Own Adventure" type book, but having the book actually be rewritten based on toggle button selections....

[Ryn]

Nothing wrong with creating an epub3 book for a client, just as long as they know that the spec is not universally supported and they would be marketing their book to clients using a specific device.

Same goes for books that work with scripting solutions supported by one vendor only.

Is this situation perfect? Surely not, but Toxaris' perpetual frowny conservatism also helps no-one.

To me, there is nothing inherently wrong with the epub3 standard, such as it is. In fact, the possibilities are tantalisingly close. Now we just have to brave the cross-currents of the standards battle and all of us ebook makers will be just fine. Know what's possible, and to what extent; then advise your client to the best of your knowledge.

[Toxaris]

I think you are mistaken my view with someone else. It is true that I see faults in the format.

I don't mind people making books specifically for iBooks, just don't call them ePUB, since they are not. I also have no objection to ePUB3 books, as I stated before I do see some usage in them for specific types of books.

However, what I do object about that instead of looking to the problems there were with the old version and fix those, they listened too closely to Apple and Co and were too eager to put in all kind of stuff with regards to multimedia. There were already enough possibilities for those (called apps...).
The addition of Javascript sounds nice on the surface, but if you think about it. Remember the time when javascript was just new for websites? Remember how it looked then?
The format itself is definitly not perfect and will create a lot of problems, especially with the interpretation of it. I am far from conservative, but I do object to progress in the name of progress. It must add something useful and in my book audio/video/scripting is not.

[JSWolf]

I have to agree that we don't need all the scripting/audio/video. It is going to bloat the heck out of eBooks and that is not good.

Before any soft of multimedia is added, I feel we need to get the book parts actually correct.

[dgatwood]

Originally Posted by JSWolf

Before any soft of multimedia is added, I feel we need to get the book parts actually correct.

Ah, but you see, that's not how the technology industry works. You see, they never get the core parts right. They just keep coming up with cool new features so that people don't notice that the core functionality doesn't work....

[AlPe]

I jumped into this thread very late, so please forgive if I do not quote/reply. I just list my thoughts on the arguments raised.

1) Is it a common practice to say "we do a lot of wonderful eBooks with animations and such"? Unfortunately yes. I say "unfortunately" because they usually do not explain to their clients that those features will work only in iBooks on the iPad. While technicly true that they are creating valid (say) EPUB 3 eBooks, they are not behaving according to professional ethics.

[ Example: my company is producing the first Audio-eBooks in EPUB 3 format, with Media Overlay support ("dynamic highlighting") for reflowable eBooks (not FXL). We clearly stated to our client the limits of the current support, etc. They still decided to accept the fallbacks and bet on future better support. --- You can download some of these EPUB 2+3 from my company website, see the link below ]

2) Putting Javascript inside EPUB 2: absolutely a waste of time.

3) Putting Javascript inside EPUB 3: maybe. Again, if the client really wants an iPad-only stuff, it might be ok.

4) iBooks is not officially supporting EPUB 3 spec, because they are lacking support for some mandatory parts of the spec, like full MathML (iBooks supports a subset of it), and Media Overlays in reflowable eBooks.

5) Multimedia in eBooks. We need to define "multimedia" and "eBook" here. A decent mechanism of fallbacks might be acceptable on some contexts (say, when video/audio is NOT essential to the rest of the "experience"), while it might be unacceptable in other circumstances (e.g., an Audio-eBook).

6) EPUB 2+3: again, we should define it. If by that you mean "EPUB 3 + NCX", then I have not found a reader yet that refuses to open such a thing. Of course, the "EPUB 3" part should be "EPUB 2 with the syntax of EPUB 3" (i.e., cosmetic differences in the markup --- stuff like <section> should be interpreted like <div>, etc.). --- You can download some of these EPUB 2+3 from my company website, see the link below.

7) I agree EPUB 3 is not the definitive answer to the "eBook industry" needs. And the support to "semantic niceties" is simply non-existing (or very buggy, like in Readium).

[AlPe]

Originally Posted by JSWolf

I feel we need to get the book parts actually correct.

I totally agree.