Possible replacement for EPUBCHECK - Page 5

KevinH · Yesterday, 12:28 PM

When on earth did epubcheck start allowing bare text whose direct parent is the body tag under epub3. At one time was an error (even under epub3).

That is definitely not a good epubcheck change, imho. It should still be a warning or usage level at least.

JSWolf · Yesterday, 03:18 PM

Quote:

Originally Posted by KevinH

When on earth did epubcheck start allowing bare text whose direct parent is the body tag under epub3. At one time was an error (even under epub3).

That is definitely not a good epubcheck change, imho. It should still be a warning or usage level at least.

I just tested @Doitsu's ePub3 code and epubcheck did not show an error for the bare text. The calibre error checker did show an error.

We've just found a bug in epubcheck.

Kayadelenium · Yesterday, 04:53 PM

Quick thought I'd like your take on — not a vote, just curious where I'm wrong.

On Doitsu's second point: it turns out that's an EPUB 2 (XHTML 1.1, block-only body) content-model rule. In EPUB 3 the same markup is valid, so epubveri already matches epubcheck there.

My leaning: rather than build out EPUB 2's older content model, I'd rather put that effort into getting ahead on EPUB 3.4 — new features to validate (AVIF/JXL, Opus/AAC, XHTML-only, TTF, SHA-1 phase-out) that epubcheck doesn't cover yet. New production is EPUB 3, and that's where a validator earns its keep.

So EPUB 2 content-model checks would stay partial (documented), extended later if there's real demand.

@KevinH — you know this landscape better than most: in your world, is EPUB 2 validation still worth deep investment, or is 3.x/3.4 the right bet? Genuinely curious what you'd do.

On a related note — since 0.5.0 epubveri can emit its results as machine-readable JSON (--format json), and the WASM build/browser demo return the same structure. Might be a useful hook for anyone thinking about tooling/editor integration.

KevinH · Yesterday, 07:14 PM

As much as I would love to leave epub2 to bitrot, there are still many tools and places (Europe, etc) where epub2 still dominates. So I would focus on epub 3.3 first (not the epub 3.4 extensions that have not been adopted by anyone yet) and then epub2 compliance.

But that is your call.

Yes, the json output should allow a Sigil plugin to be developed to integrate its results right into Sigil's validation window.

KevinH · Yesterday, 07:36 PM

Here is why bare text in the body tag is a really bad idea:

Quote:

Yes, bare text is technically allowed directly inside the body tag under modern ⁠HTML5 standards. The specification permits "flow content" within the body, which includes plain text nodes.

However, placing bare text directly in the body is strongly discouraged and considered a poor development practice.

Why You Should Avoid Bare Text

1. No Styling Control: You cannot target bare text with specific CSS rules unless you apply the style to the entire <body> element.

2. Layout Issues: Bare text cannot be easily positioned, flexed, or structured using modern layout tools like CSS Grid or Flexbox.

3. Semantic Weakness: Browsers and screen readers cannot tell if the text is a paragraph, a heading, or a caption. This hurts web accessibility.

4. SEO Disadvantages: Search engine web crawlers rely on semantic tags to rank and understand your content hierarchy.

The Better Approach

Always wrap your text in appropriate structural or semantic elements:

Use <p> for standard paragraphs.
Use <h1> through <h6> for headings.
Use <span> for small, inline text styling.
Use <div> or <section> for grouping content blocks.

I think we should file a bug report with epubcheck and ask them to at least put back a warning for bare text inside the body, at the very least on Accessibility grounds if nothing else.

Update:

I added a bug report: https://github.com/w3c/epubcheck/issues/1671

Please add your 2 cents to that issue, if you feel strongly about it one way or the other.

Kayadelenium · Today, 04:16 AM

Two quick updates.

On the bare-text-in-<body> discussion (and Kevin's epubcheck issue #1671): I added a note there in support of a warning-level treatment. Briefly — bare text directly in <body> really is valid HTML / EPUB 3 flow content, so it isn't a validity error; but the accessibility and semantic concerns are real, which is exactly why a usage/warning framed as accessibility guidance fits better than a hard content-model error. I think a warning (as Kevin proposes) is the right call, and epubveri will follow whatever epubcheck lands on here rather than get ahead of it.

epubveri v0.5.3 is out (all channels — prebuilt binaries, crates.io, the browser demo, and npm):
- Deprecated metadata <link rel> keywords — the legacy marc21xml-record / mods-record / onix-record / xmp-record and xml-signature — now draw a warning (OPF-086), matching epubcheck.
- Under the hood, the --format json output types were made reusable across tooling — groundwork toward the kind of editor integration Kevin mentioned (a Sigil plugin reading epubveri's JSON results).

As always, bug reports welcome on GitHub.

JSWolf · Today, 07:17 AM

That's good that epubveri warns about bare text in ePub3.

KevinH · Today, 07:41 AM

And fwiw, I think the epubcheck using "whatever is valid in html5" as the standard for acceptance, is in general a huge mistake.

Html5 accepts pure slop code that basically has few if any guidelines.

Since epub 3 already requires its xhtml variant, with xml syntax rules (no implied closing tags, no adoption agency spaghetti code, etc) epubcheck should be applying much stricter (best practice) kinds of rules to nudge the user base into better practices in code usage and accessibility.

And Html5 is simply not a workable standard for archival publishing because it and its css are constantly being changed because they are living standards. To make matters worse, Html5 and css change in much shorter cycletimes than would be expected for a published book/epub which should still be readable in decades.

For example, just because modern css now allows native fully nested selectors, does not mean it should be accepted into an epub3. As far as I know the w3c java css validator still rejects it (and I hope it stays that way).

IMHO, epubcheck and other validators should understand their role is to act as gatekeeper and nursemaid to keep pure junk out of the epub marketplace and encourage better and more stable code that will work across all e-readers for decades and has improved Accessibility. Epubs are not websites.

Yesterday, 07:14 PM	#64
KevinH Sigil Developer Posts: 9,788 Karma: 7500000 Join Date: Nov 2009 Device: many	As much as I would love to leave epub2 to bitrot, there are still many tools and places (Europe, etc) where epub2 still dominates. So I would focus on epub 3.3 first (not the epub 3.4 extensions that have not been adopted by anyone yet) and then epub2 compliance. But that is your call. Yes, the json output should allow a Sigil plugin to be developed to integrate its results right into Sigil's validation window. Last edited by KevinH; Yesterday at 07:16 PM.

Today, 07:41 AM	#68
KevinH Sigil Developer Posts: 9,788 Karma: 7500000 Join Date: Nov 2009 Device: many	And fwiw, I think the epubcheck using "whatever is valid in html5" as the standard for acceptance, is in general a huge mistake. Html5 accepts pure slop code that basically has few if any guidelines. Since epub 3 already requires its xhtml variant, with xml syntax rules (no implied closing tags, no adoption agency spaghetti code, etc) epubcheck should be applying much stricter (best practice) kinds of rules to nudge the user base into better practices in code usage and accessibility. And Html5 is simply not a workable standard for archival publishing because it and its css are constantly being changed because they are living standards. To make matters worse, Html5 and css change in much shorter cycletimes than would be expected for a published book/epub which should still be readable in decades. For example, just because modern css now allows native fully nested selectors, does not mean it should be accepted into an epub3. As far as I know the w3c java css validator still rejects it (and I hope it stays that way). IMHO, epubcheck and other validators should understand their role is to act as gatekeeper and nursemaid to keep pure junk out of the epub marketplace and encourage better and more stable code that will work across all e-readers for decades and has improved Accessibility. Epubs are not websites. Last edited by KevinH; Today at 07:55 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
EPUBCheck v4.2.6	jhowell	ePub	0	06-30-2021 03:49 PM
EPUBCheck v4.2.5	jhowell	ePub	0	03-23-2021 09:45 AM
EPUBCheck v4.2.4	jhowell	ePub	3	06-24-2020 09:51 AM
EPUBCheck v4.1.1	Doitsu	ePub	2	03-18-2019 10:39 AM
Web-based epubcheck upgraded to epubcheck 1.0.5	kjk	ePub	4	02-09-2010 09:53 PM

Yesterday, 12:28 PM	#61
KevinH Sigil Developer Posts: 9,788 Karma: 7500000 Join Date: Nov 2009 Device: many	When on earth did epubcheck start allowing bare text whose direct parent is the body tag under epub3. At one time was an error (even under epub3). That is definitely not a good epubcheck change, imho. It should still be a warning or usage level at least.

Yesterday, 04:53 PM	#63
Kayadelenium Member Posts: 11 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Quick thought I'd like your take on — not a vote, just curious where I'm wrong. On Doitsu's second point: it turns out that's an EPUB 2 (XHTML 1.1, block-only body) content-model rule. In EPUB 3 the same markup is valid, so epubveri already matches epubcheck there. My leaning: rather than build out EPUB 2's older content model, I'd rather put that effort into getting ahead on EPUB 3.4 — new features to validate (AVIF/JXL, Opus/AAC, XHTML-only, TTF, SHA-1 phase-out) that epubcheck doesn't cover yet. New production is EPUB 3, and that's where a validator earns its keep. So EPUB 2 content-model checks would stay partial (documented), extended later if there's real demand. @KevinH — you know this landscape better than most: in your world, is EPUB 2 validation still worth deep investment, or is 3.x/3.4 the right bet? Genuinely curious what you'd do. On a related note — since 0.5.0 epubveri can emit its results as machine-readable JSON (--format json), and the WASM build/browser demo return the same structure. Might be a useful hook for anyone thinking about tooling/editor integration.

Today, 04:16 AM	#66
Kayadelenium Member Posts: 11 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Two quick updates. On the bare-text-in-<body> discussion (and Kevin's epubcheck issue #1671): I added a note there in support of a warning-level treatment. Briefly — bare text directly in <body> really is valid HTML / EPUB 3 flow content, so it isn't a validity error; but the accessibility and semantic concerns are real, which is exactly why a usage/warning framed as accessibility guidance fits better than a hard content-model error. I think a warning (as Kevin proposes) is the right call, and epubveri will follow whatever epubcheck lands on here rather than get ahead of it. epubveri v0.5.3 is out (all channels — prebuilt binaries, crates.io, the browser demo, and npm): - Deprecated metadata <link rel> keywords — the legacy marc21xml-record / mods-record / onix-record / xmp-record and xml-signature — now draw a warning (OPF-086), matching epubcheck. - Under the hood, the --format json output types were made reusable across tooling — groundwork toward the kind of editor integration Kevin mentioned (a Sigil plugin reading epubveri's JSON results). As always, bug reports welcome on GitHub.

Today, 07:17 AM	#67
JSWolf Resident Curmudgeon Posts: 84,119 Karma: 153695583 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	That's good that epubveri warns about bare text in ePub3.

Advert

Advert