[KevinH]

And epub 3 finally took off especially in Japan and internationally. That alleviated part of the need for an epub 4, especially from the newly adopted epub3 publishers. Plus the potential to lose the large installed base of epub users whose devices would not support it.

All in all, the epub4 spec as written was clearly a product of a committee well removed from actual coding and tool chains used in publishing. A lot of existing tools in e-publishing rely in part or full on the strict syntax of xhtml/xml (i.e, almost all regular expressions based parsing do for example) and would need to be completely rewritten to allow for the more spaghetti-like rules of html, free floating '<'s, node injection rules, etc, that a real html parser must account for (take a peak at the html whatwg spec to see the complexity required by a real html parser.)

I personally am much happier with the slower evolution of the epub 3.x spec, and the intelligent deprecation of epub3's more esoteric features not easily supported in browsers such as trigger, switch, refines of refines, the substitution of epub:type with existing aria-role attributes.

Evolving the spec by slight changes and warnings in new releases of epubcheck, is much better approach for the e-publishing industry.