Every attempt (even my own) to fix EPUB or replace PDFs with something like EPUB to date either underestimates the problem or misunderstands it entirely.
First EPUB only supported fixed versions of XHTML and CSS. Stability and portability, right? But then development gets harder and harder the more HTML5 evolves and diverges from the original snapshot.
Update to a living spec? But then you lose that stability and predictability.
@castedo No, I’ve had several goes at this over the years. I’ve been involved in the ebook/epub scene for almost 20 years, since my PhD days, even before it was called EPUB 🙂
@baldur 😇 yeah. On a more serious note, I see the main problem in the lack of acknowledgment from the spec folks that there are real world problems that they can (and should) help solve.
They've just given up, pretending like they solved the problem.
Interactive pagination is massively underspecified in CSS. Even print/pdf pagination is underspecified. Every ebook app is going to render it just a bit differently
Publishers want the book to look the way they designed it but then deliver garbage CSS and markup
Readers want to be able to change every setting, even if that means nuking the publisher styles
Ebook stores want the ebooks to represent their brand colours and typography even though they weren't designed for reading in mind
@baldur in my space (higher ed), specialized apps are moving away from pagination. Seems like students like to scroll like any other web content. Who'd have thunk it.
Publishers want ebooks to be able to connect to the network to load assets and inject analytics
Readers hate that
Ebook apps also hate it because if you think websites are bad, the publishing industry has all of that amoral greed but even less technical competence. A publishing industry exec will turn almost any given tech to shit just by breathing in the same room as the devs. Also, ebooks, being portable and detached from the origin system, are much more of a security hazard than you'd guess
Browser vendors are barely able to maintain XHTML support and SVG lags far behind the shiny shiny, so every ebook app development starts with a massive handicap.
Every single part of your stack is a derelict corner of the web, already falling apart from neglect. But you're also expected to implement an unspecified variation of CSS in user space because app stores won't let you ship a custom browser engine, and even if they did, there isn't enough money to warrant the effort.
And JavaScript? How JS interacts with the ebook structure is also completely unspecified. And because you have to implement rendering and customisation client side, any JS you allow is inevitably going to be able to mess with the implementation details of your app in some way. You can minimise that but it's hard to prevent entirely.
And we haven't even gone into any of the advantages that PDFs genuinely have that keep it entrenched.
But, sure, another EPUB fork is going to fix everything. FINE
@baldur after a second look, I really can't. I'd rip into the quality (not even loading in incognito firefox, a hidden toc I can tab into, lots of unsubstantiated claims etc) but I think my response is much simpler: how does this help users? I see not a single point on that.
@baldur most dedicated reading systems, like the Kindle, nook, etc., don’t allow JavaScript. So those components won’t work. (Apple Books the main exception here). Most days I’d be happy just to get them to display tables correctly, and be able to keep figures and captions together.
@maccruiskeen This is not entirely true. Some of Kobo's systems do allow JS. As do many of the systems used by ebook retailers in Europe. Readium SDK supports JS out of the box so any system that's based on or forked from that is going to support JS (badly)
Nook is abandonware, so it's a miracle that anything works on it
Though, the systems that do support JS tend to do it in such an inconsistent way as to make it effectively useless. Like only supporting it on the iPad or on their own tablets
@baldur
> Update to a living spec? But then you lose that stability and predictability.
What do you mean by that? "don't break the web" is one of the web's guiding principles. A lot of reference material that would have been printed in books decades ago is available on the web. What stability and predictability do they lose by using HTML/CSS?
@zack So, originally EPUB specs (and EPUB's predecessor) were defined in terms of specific version snapshots of various web specs, XHTML, CSS, etc. This was extremely attractive for device manufacturers who didn't expect their devices to ever get updated
The problem is that browser implementation is not fixed to specific versions or snapshots. There's no way for you to say "load this XHTML file using just the features in XHTML 1.1". It's what's currently in XHTML5 or nothing.
@zack This is a problem because spec-compliant devices and apps that are built around a single version of XHTML will fail in ugly ways if they encounter unfamiliar elements like those you get in HTML5. XHTML5 is also not entirely compatible with regular HTML (doesn't reliably support module scripts, for example)
XHTML was supposed to be the next big thing when these formats were originally specified, and it's all but impossible to dislodge it from EPUB today, for a variety of reasons.
@zack Yes. But this also means you can't use a web dev toolchain any more as those will get updated to use new features and new elements and your new EPUBs would have crashed many EPUB2 devices.
This is why EPUB3 switched to the "living" specs instead of the version snapshots that EPUB2 relied on. The cost of maintaining an entirely parallel dev ecosystem was too high.
Add comment