Your EPUB passes every validator. Kobo still chokes on it. The culprit is from 2013

A book that passes the validator and still dies on the device

In his post, André Klein describes the moment every ebook maker dreads: months of work, a clean pass on epubcheck, and then a blank or mangled page on a Kobo with no error message at all. He tracks it to one line of CSS — max-width: min(150px, 30vw) — which is valid CSS Level 4 and which Kobo's rendering engine silently refuses to parse.

That engine is Adobe's RMSDK, built around 2010 for EPUB2 and, in Klein's words, "frozen in approximately 2013." It has no flexbox, no grid, no CSS custom properties, no min()/max()/clamp(). The failure mode isn't a fallback — modern CSS makes it crash. And because Kobo picked RMSDK "probably for DRM reasons," the lock-in is structural, not accidental. His practical fix is grim: test in Adobe Digital Editions by hand, because RMSDK conformance can't be checked by any standard tool.

Whose fault is it — Adobe's frozen parser, or the spec that keeps moving?

The thread splits on where to point the finger. One camp says epubcheck is doing exactly its job, and Kobo failing on the #2 ebook reader on the market is the real scandal.

"isn't that kind of the point of epubcheck? It's surely not intended to validate all of CSS, it's intended to validate that an epub will work… and not working on Kobo devices (probably #2 manufacturer of ebook readers?) is a major issue" — Danpalmer, a Google Android SRE

The other camp says the EPUB standard itself created this trap by bulk-importing browser specs that never stop changing.

"When W3C, Inc. took over maintenance of the EPub spec… they just referenced WHATWG HTML and other ever-expanding browser specs. Being 'living standards', these have no versioning or QA… Epub 3.2 just made existing epubs non-conforming. Which is why Calibre and other tool still recommend 3.1 or better yet 2" — tannhaeuser, who maintains a markup/SGML toolchain

A reader pointed out that the EPUB spec never even promises which CSS version a renderer must support, so calling RMSDK "broken" is itself contestable — there were never guarantees min() would work.

The asterisk: you literally cannot license the engine everyone depends on

The sharpest detail came from someone who tried to build on RMSDK rather than around it.

"There is no way to get access to it… There is no one to talk to. The email listed on their website does not respond to anything… I messaged a former colleague who worked there… He said he tried to find internal docs about it and couldn't find anything" — nfw2, an ereader-software developer

The abandonment is now official: Adobe Digital Editions and RMSDK were sold to Wipro, a handoff one reader called "botched." Kobo is responding by routing around Adobe entirely.

"Kobo is actually in the process of completely rewriting their e-reader software… and I'm pretty sure it's no longer based on RMSDK. Adobe basically handed the EPUB DRM market to LCP on a silver platter by being a poor maintainer and then selling off to a third party" — chocolatkey, an ebook-tooling developer

A different escape hatch came up repeatedly: name the file .kepub.epub to trigger Kobo's newer engine, run it through kepubify, or sideload KoReader, which every Kobo can run.

The pattern under the bug

This isn't a one-off CSS gotcha. It's a 2010 engine kept alive for DRM, validated by a tool that can't see inside it, mandated by a spec that keeps redefining what "valid" means. The acdha thread comment drew the obvious parallel: Adobe did exactly this with Flash — shipped staggeringly bad software, ignored reduced-test-case bug reports, and eventually united every browser vendor against it. The remarkable thing is that the same company managed to do it twice, and that the open EPUB format ended up just as captive to a proprietary renderer as the web once was to Flash.