TL;DR: the title says it all, and it's available there.
Eons ago, at a time BlueGriffon
was only a Wysiwyg editor for the Web, my friend Mohamed
Zergaoui asked why I was not turning BlueGriffon into an EPUB
editor... I had been observing the electronic book market since the early days
of Cytale and its
Cybook but I was not involved into it on a daily basis. That seemed not
only an excellent idea, but also a fairly workable one. EPUB is based on
flavors of HTML so I would not have to reinvent the wheel.
I started diving into the EPUB specs the very same day, EPUB
2.0.1 (released in 2009) at that time. I immediately discovered a
technology that was not far away from the Web but that was also
clearly not the Web. In particular, I immediately saw that two crucial
features were missing: it was impossible to aggregate a set of Web pages
into a EPUB book through a trivial zip, and it was impossible to unzip a
EPUB book and make it trivially readable inside a Web browser even with graceful degradation.
When the IDPF started working on EPUB 3.0 (with its 3.0.1 revision) and
3.1, I said this was coming too fast, and that the lack of Test Suites
with interoperable implementations as we often have in W3C exit criteria was a critical issue. More importantly, the market was, in my opinion,
not ready to absorb so quickly two major and one minor revisions of EPUB
given the huge cost on both publishing chains and existing ebook bases. I
also thought - and said - the EPUB 3.x specifications were suffering from
clear technical issues, including the two missing features quoted above.
Today, times have changed and the Standards Committee that oversaw the
future of EPUB, the IDPF, has now merged
with the World Wide Web Consortium
(W3C). As Jeff Jaffe, CEO of the W3C, said at that time,
Working together, Publishing@W3C will bring exciting new capabilities
and features to the future of publishing, authoring and reading using
Web technologies
Since the beginning of 2017, and with a steep acceleration during spring
2017, the Publishing@W3C
activity has restarted work on the EPUB 3.x line and the future EPUB 4
line, creating a EPUB
3 Community Group (CG) for the former and a Publishing
Working Group (WG) for the latter. If I had some reservations about
the work division between these two entities, the whole thing seemed to be
a very good idea. In fact, I started advocating for the merger between
IDPF and W3C back in 2012, at a moment only a handful of people were
willing to listen. It seemed to me that Publishing was a underrated
first-class user of Web technologies and EPUB's growth was suffering from
two critical ailments:
- IDPF members were not at W3C so they could not confront their
technical choices to browser vendors and the Web industry. It also meant
they were inventing new solutions in a silo without bringing them to W3C
standardization tables and too often without even knowing if the
rendering engine vendors would implement them.
- on another hand, W3C members had too little knowledge of the
Publishing activity, that was historically quite skeptical about the
Web... Working Groups at W3C were lacking ebook expertise and were
therefore designing things without having ebooks in mind.
I was then particularly happy when the merger I advocated for was
announced.
As I recently wrote
on Medium, I am not any more. I am not convinced by the current
approach implemented by Publishing@W3C on many counts:
- the organization of the Publishing@W3C activity, with a Publishing
Business Group (BG) formally ruling
(see Process section, second paragraph) the EPUB3 CG and a Steering
Committee (see Process section, first paragraph) recreated
the former IDPF structure inside W3C. The BG Charter even says
that it « advises W3C on the direction of current and future
publishing activity work » as if the IDPF and W3C did not merge and as if W3C was still only a Liaison.
It also says « the initial members of the Steering Committee shall
be the individuals who served on IDPF’s Board of Directors immediately
prior to the effective date of the Combination of IDPF with W3C
», maintaining the silo we wanted to eliminate.
- the EPUB3 Community Group faces a major technical challenge, recently
highlighted by representatives of the Japanese Publishing Industry: EPUB
3.1 represents too much of a technical change compared to EPUB 3.0.1 and
is not implementable at a reasonable cost in a reasonable timeframe for
them. Since EPUB 3 is recommended by the Japanese Government as the
official ebook format in Japan, that's a bit of a blocker for EPUB 3.1
and its successors. The EPUB3 CG is then actively discussing a potential
rescindment of EPUB 3.1, an extraction of the good bits we want to preserve, and the release of a EPUB 3.0.2
specification based on 3.0.1 plus those good bits. In short, the EPUB 3.1 line, that saw important
clarifying changes from 3.0.1, is dead.
- the Publishing Working Group is working on a collection of
specifications known as Web Publications (WP), Packaged Web Publications
(PWP), and EPUB 4. What these specifications represent is extremely
complicated to describe. With a daily observation of the activities of
the Working Group, I still can't firmly say what they're up to, even if
I am already convinced that some technological choices (for instance
JSON-LD for manifests) are highly questionable and do not « lead
Publishing to its full Web potential », to paraphrase the famous W3C
motto. It must also be said that the EPUB 3.1 hiatus in the EPUB3 CG
shakes the EPUB 4 plan to the ground, since it's now extremely clear the
ebook market is not ready at all to move to yet another EPUB version,
potentially incompatible with EPUB 3.x (for the record,
backwards-compatibility in the EPUB world is a myth).
- the original sins of EPUB quoted above, including the two missing
major features quoted in the second paragraph of the present article, are a minor requirement only. Editability of EPUB, one of the greatest flaws of
that ecosystem, is still not a first-class requirement if not a
requirement at all. Convergence with the Web is severely encumbered by
personal agendas and technical choices made by one implementation vendor
for its own sake; the whole W3C process based on consensus is worked
around not because there is no consensus (the WG minutes show consensus
all the time) but mostly beacause the rendering engine vendors are still
not in the loop and their potential crucial contributions are sadly missed. And they are not in the loop because they don't
understand a strategy that seems decorrelated from the Web; the financial impact of any
commitment to the Publishing@W3C is then a understandable no-go.
- the original design choices of EPUB, using painful-to-edit-or-render XML dialects, were also an original sin. We're about to make the same mistake, again and again, either retaining things that partly block the software ecosystem or imagining new silos that won't be editable nor grokable by a Web Browser. Simplicity, Web-centricity and mainstream implementations are not in sight.
Since the whole organization of Publishing @W3C is governed by the merger
agreement between IDPF and W3C, I do not expect to change anyone's mind
with the present article. I only felt the need to express my opinion, in
both public and private fora. Unsurprisingly, the feedback to my private
warnings was fairly negative. In short, it works as expected and I should
stop spitting in the soup. Well, if that works as expected, the
expectations were pretty low, sorry to say, and were not worth a merger between two Standard Bodies.
I have then decided to work on a different format for electronic
books, called WebBook. A format strictly based on Web
technologies and when I say "Web technologies", I mean the most basic
ones: html, CSS, JavaScript, SVG and friends; the class of specifications
all Web authors use and master on a daily basis. Not all details are
decided or even ironed, the proposal is still a work in progress at this
point, but I know where I want to go to.
I will of course happily accept all feedback. If people like my idea,
great! If people disagree with it, too bad for me but fine! At least
during the early moments of my proposal, and because my guts tell me my
goals are A Good Thing™️, I'm running this as a Benevolent Dictator, not
as a consensus-based effort. Convince me and your suggestions will make it
in.
I have started from a list of requirements, something that was never done
that way in the EPUB world:
-
one URL is enough to retrieve a remote WebBook instance, there is no
need to download every resource composing that instance
-
the contents of a WebBook instance can be placed inside a Web site’s
directory and are directly readable by a Web browser using the URL for
that directory
-
the contents of a WebBook instance can be placed inside a local
directory and are directly readable by a Web browser opening its index.html
or index.xhtml
topmost file
-
each individual resource in a WebBook instance, on a Web site or on a
local disk, is directly readable by a Web browser
-
any html document can be used as content document inside a WebBook
instance, without restriction
-
any stylesheet, replaced resource (images, audio, video, etc.) or
additional resource useable by a html document (JavaScript, manifests,
etc.) can be used inside the navigation document or the content
documents of a WebBook instance, without restriction
-
the navigation document and the content documents inside a WebBook
instance can be created and edited by any html editor
-
the metadata, table of contents contained in the navigation document
of a WebBook instance can be created and edited by any html editor
-
the WebBook specification is backwards-compatible
-
the WebBook specification is forwards-compatible, at the potential
cost of graceful degradation of some content
-
WebBook instances can be recognized without having to detect their
MIME type
-
it’s possible to deliver electronic books in a form that is
compatible with both WebBook and EPUB 3.0.1
I also made a strong design choice: the Level 1 of the specification will
not be a fit-all-cases document. WebBook will start small, simple and
extensible, and each use case will be evaluated individually, sequentially
and will result in light extensions at a speed the Publishing industry can
bear with. So don't tell me WebBook Level 1 doesn't support a given type
of ebook or is not at parity level with EPUB 3.x. It's on purpose.
With that said, the WebBook
Level 1 is available here and, again, I am happily accepting Issues
and PR on github.
You'll find in the spec references to:
- « Moby Dick » released as a WebBook instance
- « Moby Dick » released as a EPUB3-compatible WebBook instance
- a script usable with Node.js to automagically convert a EPUB3 package
into a EPUB3-compatible WebBook
My EPUB Editor BlueGriffon is
already modified to deal with WebBook. The next public version will allow
users to create EPUB3-compatible WebBooks.
I hope this proposal will show stakeholders of the Publishing@W3C
activity another path to greater convergence with the Web is possible.
Should this proposal be considered by them, I will of course happily
contribute to the debate, and hopefully the solution.