EPUB CSS output could be improved quite a lot
So I’m currently in charge of Readium CSS, which is a project related to Readium 2 (link: https://github.com/readium/readium-2), a complete rewrite of Readium SDK, which you may know in the form of a Chrome app – this Chrome app is actually advised by InDesign engineers in the InDesign forums whenever a rendering issue pops up so I assume InDesign engineers know it exists.
Unfortunately, there are a lot of CSS issues piling up right now and InDesign’s output could really do with some significant improvements to allow for better cross-platform support and rendering. Indeed, Readium 2/CSS is meant to be used with any stack/rendering engine, so it won’t be tied to Webkit, and that changes the situation quite a lot.
I won’t necessarily go into details since the User Experience of posting this idea is abysmal (can see like 5 lines of text right now and I can’t expand the textarea) but here’s some issues for which a fix would be greatly appreciated:
1. if you’re outputting prefixed properties, please output all necessary prefixed properties and the standard one. It’s indeed been a bad practice to not do so and it creates severe maintenance issues for Reading Systems over the long term (for vertical writing in Japanese for example, we’ll have to pre-process stylesheets and add the missing CSS properties so that it can render well on all platforms);
2. for transforms, which are sometimes used for objects (scaled, rotated, etc.), I can’t guarantee rendering will be OK, especially as only some prefixed CSS properties are output (Kobo now has a specific guideline addressing this issue);
3. more generally, the default for objects’ output (e.g. images), with the container sized using pixels values, is plain wrong – it only works because we have safeguards to deal with it, so that images don’t become a huge mess. Same for iBooks BTW, which even have a specific CSS declaration in its default stylesheet just because of that.
4. absolute positioning, which is sometimes used for objects with several images/frames, is explicitly discouraged in the EPUB spec itself for reflowable text so you should assume it will create rendering issues in at least some Reading Systems;
5. the way embedded fonts are output (font-family) is wrong, and puts a burden upon other authors.
6. if color is black, you don’t need to output it (Kindle even had to take the liberty of sanitizing this declaration so that it doesn’t create issues in night mode i.e. it removes it entirely).
7. absolutely-positioned <span> in fixed-layout is now strongly discouraged in the iBooks guidelines because it breaks search and selection (providing users with a subpar UX).
8. you export several languages in metadata and this is fine. However, we have a spec issue there: there is nothing to define which language is the primary language of the publication, which can create significant edge cases (iBooks, for instance, defines the last language item as the primary language for the publication, which means it may lay out an english book right to left if the last item happens to be arabic because there are arabic characters here and there).
There’s more but listing them there is quite uncomfortable. So please feel free to contact me by mail if you’re willing to improve the current output. That would indeed benefit the whole ecosystem, given InDesign is quite ubiquitous in publishing, and I’ll be glad to help.
Would love to keep tabs on this - as up until I started working on more enhanced epubs with audio features and buttons that activated hidden layers, Readium was my go to eReader. Now unfortuntately there is a gap in the eReader market for Android and Windows users that Adobe digital editions is trying (but failing miserably) to fill.
I am an avid Windows and Android supporter, but when iBooks can read my InDesign epub files without a problem and services on Android and Windows can't, I find myself questioning that support.
Felipe Santos commented
Really indesign can improve in this area. But for this item - 3. more generally, the default for objects’ output (e.g. images), with the container sized using pixels values, is plain wrong
All images are export for ePUB as % and we can adjust the Wdth/Height of objects from Object Styles properties - Size in Objects Export Options