The Web Publications work over at the W3C remains utterly depressing to me. Mainly because I remain convinced that the IDPF/W3C merger guarantees that it will devolve into a reimplementation of ePub, which isn't really what browser vendors want (who want nicer ways for making the regular web publication-friendly).

So browser vendors will ignore it.

And Amazon will ignore it.

And it'll just be a rehash of the current, limited ePub ecosystem nobody likes.

@baldur yeah, that's what I'm expecting as well.

@pablod My guess is that it'll largely be irrelevant either way. The Readium group is charting its own course and don't need the W3C to confer with the few reading system implementors that actually care about compatibility.

And web devs who want to make book-like things on the web will be helped more by improvements to regular web-stuff like Service Workers and CSS than by any of what comes out of the Digital Publishing groups at the W3C.

If I had to guess. 🙂

@baldur what's readium's stance on future compatibility with the major ePub-based platforms? (I haven't been keeping up)

@pablod Well, they are committed to ePub-compatibility and to whatever its successors are.

But they also seem to be focusing instead on having open source implementations first and leaving it up to other W3C members whether they want it to standardise whatever they come up with.

Like Hadrien Gardeur's work with putting together a json-based manifest for publications. It's designed to be an internal format for Readium but they seem also open to it being standardised.

@baldur huh. It sounds like I should dip in and see what they're up to.

@pablod Most of the interesting Readium stuff is over at https://github.com/readium/readium-2

The JSON manifest/web publications stuff being made by Readium: https://github.com/HadrienGardeur/webpub-manifest

This isn't in the W3C process, AFAICT, but that's largely because the digital publishing groups at the W3C are stuck in busywork mode ATM. (Writing a charter that appeases the IDPF and browser crowd. Putting together an excessively complicated requirements doc, etc.)