EPUB 3.3 BECOMES A W3C RECOMMENDATION

[jmurphy]

https://www.w3.org/blog/news/archives/9919

[DNSB]

Finally!

[Quoth]

I think there should be a fork. Epub 3.x has much that's irrelevant to static ebooks. Audio, animation, video and interactive (other than screen/window reflow) has no place in an ebook standard. Browser capabilities rather than features needed for static electronic copies of printed books has too much driven this.

We saw the same with PDFs. The PDF development should have forked, one fork to preview or replicate or source for paper print and the other fork for filling in forms, interactive, multimedia etc.

Feature creep in the wrong direction. A horse designed by a committee. Inevitable when epub was rolled into the W3 org. There is also no need for Fixed Layout Epub. That is as well served by a PDF.

Obviously better support for maths/formula, vector graphics, fonts, languages, multicolumn etc was needed than in epub2 which was a missed opportunity.

I want ebooks that can replicate any print document. I don't want "Harry Potter" style ebooks, or ebooks aspiring to be merely paginated versions of multimedia interactive websites, though a web browser that paginates, has jump to page and TOC like an ebook would be an improvement over the scrolling. Scrolls are so 2000 years ago.

[KevinH]

There is no need for a fork. There never has been. You seem to ignore the fact that no one says you have to use any of those "features" if you do not want to.

And you are still missing that epub3 does standard fiction much much better than epub2 ever did with much better internationalization support and much better Accessibility (naming just two areas of improvement).

Always harping on epub3 because it supports audio, video, etc. while completely ignoring that it is a huge improvement for standard fiction as well just makes no sense.

[theducks]

There are just too many variants.
We need a user tool to check 'this is compatible/usable with my device'.

Just look at the KFX hoo-ha that non-Kindle users deal with .

Look at how many K3 and before are still in use . Or how many brands are gone with no possible FW update from early ADE.
Not everyone wants to bin (or can afford to), an old model, let alone deal with the DRM induced consequences on their older purchases.

[Aleron Ives]

Originally Posted by Quoth

Feature creep in the wrong direction.

I have a feeling this has contributed to the persistence of EPUB 2. Some people no doubt have a visceral reaction to the fact that EPUB 3 has so many bells and whistles that never should have been introduced and decide to use the "purer" e-book standard, instead.

[Quoth]

Originally Posted by KevinH

There is no need for a fork. There never has been. You seem to ignore the fact that no one says you have to use any of those "features" if you do not want to.

Big publishers and self publishers will use the features because they are there.

There needs to be epub3.xMM and epub3.xRP A Kitchen Sink thrown in spec is always bad. See PDF mess. It should also be two versions. Or USB-C/USB 3.0 confusion (does my devices have native video, source more than 5V, support audio gadget mode or what?)

MM multimedia: Basically paginated Multimediaa interactive web pages.
RP reflowable/resizable paper: Completely static but pages & images fit any screen. Anything seen on paper is supported, but additionally full support for TTS / Voice view and other accessibility.

I'm not ignoring any facts and certainly epub3 fixes some epub2 issues for RP format that shouldn't have needed fixed.

[DiapDealer]

Originally Posted by Quoth

Big publishers and self publishers will use the features because they are there.

Self-publishers? Who cares? They make their own bed. But big publishers have been selling EPUB3s for years without all the bells and whistles that have been available to them for that same amount of time. When exactly can we expect this explosion of unnecessary multi-media being included by big publishers?

[Grimaud]

Originally Posted by Quoth

There is also no need for Fixed Layout Epub. That is as well served by a PDF.

Maybe manga publishers are bad at PDF in France and in the US, but the rare times I had access to a PDF file for a manga I bought, none of them properly managed the Right-to-left reading direction of mangas: either they didn't care at all so any pictures spreading on two pages would not display properly (because the pages were organized as if the reading direction was LTR) or they care a bit and the pages were in the reverse order (last page as cover, cover as last page, to mimic the RTL reading direction), which allow for proper display of pictures on two pages but the reading experience was not great either because I was forced to go to the last page of the PDF file to display the cover and start reading the book.

Outside of one manga series (a mistake by the publisher who forgot to specify the reading direction in the spine section of the OPF files), all Fixed Layout EPUB mangas I bought are in the correct reading direction, so I would not say, based on my experience, that the existence of PDF means Fixed Layout EPUB should not exist.

[JSWolf]

ePub 3 introduced some code that was not needed that makes it no as compatible with older software as it should be. Things like <figure> when <div works perfectly well. hv/vw when % works perfectly well. And others.

[DiapDealer]

For God's sake, get over it already. Epub3 is not the bogeyman, or stumbling block, that you (and others) want it to be.

[jhowell]

I see the EPUB 3.3 standard as being largely irrelevant from a practical point of view. It would be one thing if they were codifying the actual standards that a publisher needs to follow in order to produce a usable book. But the stakeholders who matter the most, the major e-book reading platforms (Kindle, Kobo, Nook, and Apple Books), are not part of the standard making process and have no real incentive participate. Unfortunately those players can dictate to publishers what they will accept and having requirements that do not quite match each other is an advantage if it makes it more costly for publishers to format books that work with their competitors.

The EPUB 3.3 specification explicitly defers to other standards for the definition of supported HTML and CSS. It even mentions that as those standards evolve existing EPUB documents may become unreadable. I don't think that is a good thing.

Instead of specifying things that a reading system might support in my opinion it would be better to focus on a core minimal subset that EPUB readers already support. Then get agreement from the major players that they will continue to do so in the future. That way we would have something that has the possibility of being used to publish books that will still be readable in twenty or fifty years. Something equivalent to PDF/A which specifies a subset of PDF suitable for the long-term archival of documents.

[DiapDealer]

To be fair, it was/is largely the same for the EPUB2 standard. Publishers and eReading platform happily ignored large portions of the EPUB2 spec as it suited them. There is certainly nothing objectively worse about 3.3, and has already been mentioned, there have been objective improvements in internationalization and assistance since 3.0 that many like to gloss over because *GASP!* multimedia.

[KevinH]

In a way, the they have done that.

If you look at the first epub 3 specifications that added lots of crud like "epub:switch", and "multiple refines on refines", they have now deprecated all of that and have decided to instead focus on things supported by modern webkit/blink/browser engines. And therefore they have stopped creating differences from what the normal html (whatwg spec) allows.

That means more support not less in modern readers that typically use browser engines. They also now look at usage levels by current e-readers and publishers in their decision to deprecate little used features.

If you look at the whatwg spec, you see a living spec that is evolving but browsers engines still support all of those old features (back to html 3.2 and in some cases before such as font tags, etc).

So as long as your epub content can be read in a browser engine, it will not ever be fully lost.

Proper document archiving is a different beast entirely. That requires archiving both the operating system and application software for reading it for the long term and keeping up virtual machines to host it all. But since xhtml/html is just marked up text for the most part, almost anything will be able to extract content from it.

Everyone is looking for an ebook format that will run on all reading devices forever but that is just not going to happen. Many e-readers have never updated their firmware so there is just a hodge page of epubs with workaround kludges for those devices. And Kindle pushing its own proprietary format just makes things worse, not better.

So creating a decent epub3 version epub (without kludges for Kindle and broken devices) as the base version and archiving that is probably the best bet for archival purposes and future proofing given the ease that xhtml can be manipulated with simple software.

[ZodWallop]

Originally Posted by JSWolf

ePub 3 introduced some code that was not needed that makes it no as compatible with older software as it should be. Things like <figure> when <div works perfectly well. hv/vw when % works perfectly well. And others.

My old Nook ST has problems with things like:

margin: 1em 0 0 0;

It has to be changed to:

margin-left:0;
margin-right:0;
margin-top:1em;
margin-bottom:0;

But that is because the Nook is over a decade old. I understand that the older software it runs may not be up to current standards. I'm the one with the old reader. I do not expect publishers to keep publishing books that are 100% compatible with it on to eternity.