Repository navigation
Reflowable documents cannot be designated in spreads #1652
Description
If a spine item references a reflowable epub content document (rendition:layout=reflowable with no local spine override, or rendition:layout-pre-paginated with a local rendition:layout-reflowable override), it must not have any of the spread placement properties listed in its properties attribute.
Those properties are: page-spread-right, rendition:page-spread-right, page-spread-left, rendition:page-spread-left, and rendition:page-spread-center
Activity
bariskayadelen commentedon Jul 31, 2026
I'm implementing this rule in epubveri, an independent pure-Rust EPUB validator, so I'm coming at it as a second implementer rather than as a spec reader, and I ran into a question I can't answer from the outside.
A publication that is conformant under 3.3 becomes non-conformant under 3.4. EPUB 3.3 says:
EPUB 3.4 says:
So content that 3.3 explicitly permitted is an error under this issue's rule. Both publications declare
version="3.0", and nothing else in the container distinguishes them.That leaves a question that is squarely epubcheck's to answer: on what basis does the checker decide to apply this? As far as I can tell the only available answer is "always, to all EPUB 3 content", which makes it retroactive — books produced years ago against a spec that allowed this start reporting errors on the day 5.3.0 ships. I'd rather ask than assume, since whatever epubcheck does here becomes the de facto answer for everyone else implementing it, including me.
I also think the underlying problem is the missing version signal. A publication that uses 3.4 features — AVIF, JXL, roll layout — still has to declare
version="3.0", which to my reading is a statement the file does not meet: read as 3.3, that same file is invalid. A producer has no way to say which specification it targeted, and a validator has no way to ask. I think a full version number in the package document would make this tractable for epubcheck and for alternative engines alike.I'm aware that is exactly what EPUB 3.1 did and why 3.2 reverted it (w3c/epub-specs#1009), and I'm not asking to relitigate that: the adoption cost of requiring a new value fell on every existing file, and that cost was real. But the mechanism that failed was a mandatory version change. An optional conformance declaration would not have the same cost:
That also seems to me to answer the objection raised in w3c/epub-specs#695 against a version bump — that nothing solidly identifies the version, so tools would need an option users don't understand. Under an optional declaration the default needs no option at all; the flag only exists for the files that carry it.
If this is out of scope here and belongs in
w3c/epub-specs, I'm happy to move it — I raised it on this issue because this is the first 3.4 change I've hit where the rule itself is unambiguous and the applicability is not.EPUB 3.4: report page-spread-* on a reflowable document (ADV-005)
feat(EPUB 3.4): report spread placement of reflowable/roll content (u…
feat(EPUB 3.4): report spread placement of reflowable/roll content (u…
rdeltour commentedon Sep 16, 2026
@bariskayadelen a couple following comments on the issues you raise:
For this specific issue, the point is moot since the specification wording is not backed by an RFC 2119 keyword (MUST/SHOULD), so we report this as USAGE only. I guess having these synthetic spread properties is on reflowable/roll documents is not harmful in itself, it will just be ignored by the reading systems.
About the EPUB version targeted by EPUBCheck:
EPUBCheck basically targets the latest stable EPUB 3 version. Up til recently it was EPUB 3.3, and since v5.4.0 it is EPUB 3.4. The latter entered "Candidate Recommendation" stage, which is supposed to be very stable and close to final in the W3C rec track.
EPUB in general tries its best to be backwards compatible, but the devil is in the details and sometimes for very specific constructs it is not.
Since EPUBCheck is supposed to be a pure conformance checker, we try to not deviate from the specification. In some cases however, some backward-incompatible change might be reported with a lower severity in EPUBCheck to not "break" existing content, but it would be very rare and backed by usage data. Usually that would mean the specification is too strong and would be changed.
w3c/epub-specs😊