Possible replacement for EPUBCHECK - Page 7

JSWolf · 07-17-2026, 05:43 AM

delete post

JSWolf · 07-17-2026, 05:51 AM

I'm trying 0.5.11. Would you mind removing -i? I don't see a need for it. Thanks.

Another fix, when the CSS references named fonts but there is no @font-face for it, please flag it as either an error or a warning.

Also, please check the CSS for errors. The CSS has an error of font-eight that should be flagged as an error. There is also a class for h4a which is also an error as there is no h4a.

font-size: x-small;; was missed as an error.

DiapDealer · 07-17-2026, 07:31 AM

Quote:

Originally Posted by JSWolf

I'm trying 0.5.11. What with -i? It should not be needed. Please remove -i. Thanks.

Don't use it. Please stop conflating personal preferences with real issues.

j.p.s · 07-17-2026, 10:47 AM

Quote:

Originally Posted by JSWolf

Would you mind removing -i? I don't see a need for it. Thanks.

Yeah, well you originally didn't see a need for epubveri.

Doitsu · 07-17-2026, 01:41 PM

@Kayadelenium:

Here's one final test case. It's mostly cosmetic issues:

epubveri output:

Spoiler:

EPUbCheck output:

Spoiler:

EPUBCheck didn't check the validity of the <dc:date> value, which, IMHO, is a bug. It also didn't make sure that the <html> tag language attributes were identical.

epubveri might never become an EPUBCheck drop-in replacement, but from what I've seen so far it's often more compliant with the EPUB spec than EPUBCheck is.

Doitsu · 07-17-2026, 04:33 PM

@KevinH

Out of curiosity, I tested an epub3 book with some elements that were at one point deprecated in XHTML.

Spoiler:

epubveri flagged: big, center, font and strike.

However, EPUBCheck only flagged big and center.

EPUBCheck output:

Spoiler:

Would you agree that this is an actual EPUBCheck bug?

Kayadelenium · 07-17-2026, 06:38 PM

Hi, I released two versions, but I noticed a few more bugs; I'm working on fixing them.

Your latest test and the other tests are passing successfully. I also fixed more issues than just those related to `big`, `center`, `font`, and `strike`.

I'll let you know and write a detailed post once I've completely cleared out the bugs.

Kayadelenium · 07-17-2026, 08:28 PM

v0.5.14 is out, with Doitsu’s empty-metadata case and a first pass at JSWolf’s CSS ones.

Doitsu — empty dc: metadata (EPUB 2). Fixed: an empty (or whitespace-only) Dublin Core element in an EPUB 2 package — an empty dc

ublisher, dc:creator, and so on — now draws OPF-072 at usage level, which is what EPUBCheck reports. dc:title and dc:date are left to their own existing rules. EPUB 2 only, and usage-level, so it never changes a book’s valid/invalid verdict — it just tells you the element is carrying nothing.

JSWolf — font-eight, x-small;;, and .h4a. One is a real find, two aren’t, and I’d rather say which than quietly ship all three.

font-eight (a typo for font-weight) is the real one: a property name CSS doesn’t define. The catch is that EPUBCheck doesn’t validate property names at all — it never flags an unknown property — so reporting it by default would be me inventing an error the authority hasn’t decided on, which is the one thing I’ve said I won’t do. So it’s there, but opt-in: run with --advisory and you get ADV-001: 'font-eight' is not a recognized CSS property, at the exact line and column, at usage severity (it never affects the exit code). Same for an unknown at-rule descriptor — a bogus @font-face descriptor is ADV-002. Off by default the output is byte-for-byte what it was.

Two things worth spelling out about how it decides “unknown”, because the failure mode of a property linter is false positives:

The known-property list is the union of the W3C “all properties” index and MDN’s property data — MDN carries the legacy aliases and SVG properties the W3C index omits (word-wrap, text-rendering, and friends), which were the false positives when I tried the W3C list alone. Vendor-prefixed (-webkit-…) and custom (--…) names are exempt.
It’s a distinct message family (ADV-…), deliberately not a CSS-0xx. Matching EPUBCheck on verdicts means not minting a code in its namespace for something it doesn’t define.

The other two I checked and don’t think are errors:

x-small;; — the doubled semicolon is an empty declaration, and CSS Syntax says to just discard it. It’s valid; EPUBCheck doesn’t flag it, and neither do I. (If you meant something else by it, show me the whole rule and I’ll look again.)

.h4a — a class selector named h4a is a perfectly legal selector; there’s nothing wrong with it to report. If the intent was a different class and this is a typo, that’s a spelling question a validator can’t see — the selector itself is valid CSS.

The property-name check rides on a separate small library I’ve been building alongside this (styloria, a pure-Rust CSS parser); the validation is the part that’s new in it. Value- level checking — whether color: 3px is nonsense — is a much bigger job and isn’t in yet.

And there’s more to come — this is a first pass, not the finished picture. A few improvements are already lined up: the advisory checks only run from the command line for now (the in-browser/WASM build can’t opt in yet), value-level CSS checking is the natural next layer, and the deeper content-model work continues. I’d rather ship these in small, verifiable steps than announce a big list, so I’ll post them as they land — and this thread has been better than any roadmap for deciding what’s worth doing next.

Binaries: v0.5.14 release page. Keep them coming — the font-eight case is exactly the kind of thing I’d never have written a test for on my own.

Kayadelenium · 07-18-2026, 04:24 AM

v0.5.15 is out, and it’s the one I’d been putting off: the XHTML content model is now validated properly — the deepest, hardest part of matching EPUBCheck, and the part I said from the start I’d leave for last.

Read this first if you validate your own books: this release changes verdicts. A book that nests elements illegally, or points an attribute at an id that isn’t there, now comes back invalid (RSC-005) where 0.5.14 passed it. That’s not a regression — it’s catching real errors EPUBCheck catches too — but if a book that was green suddenly isn’t, this is almost certainly why. Check the new message before assuming something broke.

What’s actually new, in three parts:

Nesting rules — the constraints a grammar structurally can’t state, because they’re about a node’s ancestors, not its immediate contents. An <a> inside another <a>; interactive content (a <button>, a <select>, an <audio controls>) inside an <a> or <button>; a <form> inside a <form>; <header>/<footer> nested in each other; a <label> in a <label>. Element placement — the <span> and loose text directly under <body> that Doitsu reported way back — was already caught by the grammar; this is the other half.

Broken references — every id an attribute points at now has to exist, and where the reference is typed, point at the right kind of element: aria-describedby / aria-labelledby / aria-controls and friends must resolve; <label for> must target something labelable; headers must name <th> cells in the same table; aria-activedescendant must be an actual descendant. This is the one I think matters most day to day — a dangling aria-describedby is a real accessibility bug and easy to introduce by editing.

A handful of smaller structural rules — duplicate <map> names, a <select> with two selected options, more than one <meta charset>, and so on.

All of it is EPUB 3, all reported as RSC-005 at the offending element with a line and column, and all verdict-matched to EPUBCheck — I check each rule fires on the mistake and stays quiet on the valid shape, and the whole EPUBCheck test corpus is unchanged. Thanks to Doitsu for the original report (thread post #54); this closes it out.

One other thing, for the CSS crowd: the opt-in --advisory check from 0.5.14 — the one that flags a misspelled CSS property like font-eight — now works in the in-browser (WASM) build too, not just the command line. Still opt-in, still never changes a book’s verdict.

Binaries: v0.5.15 release page. As always, the fastest way to find the next bug is to point this at a book EPUBCheck disagrees with and tell me — that’s been worth more than any test I’d have written on my own.

Doitsu · 07-18-2026, 05:22 AM

Quote:

Originally Posted by Kayadelenium

v0.5.15 is out, and it’s the one I’d been putting off: the XHTML content model is now validated properly — the deepest, hardest part of matching EPUBCheck, and the part I said from the start I’d leave for last.

Thanks for adding this feature. You can test it with this MR epub.

It contains one paragraph with a misplaced </p> tag.

<p>»Auf Wiedersehen, <i>Jarl</i>!«</p>, antwortete der junge Mann schaudernd, denn das war das erste Mal, dass er den heiligen Namen Gottes von den Lippen des Kapitäns hörte.

epubveri reports this issue twice. Once with a reference to the actual line and once with a reference to the <body> tag.

ERROR RSC-005: text is not allowed directly in "body"; EPUB 2 requires block-level content
ERROR RSC-005: character data is not allowed in element "body"

IMHO, character data is not allowed in element "body" maybe technically correct, but might not be understood by the average ebook creator.

How about:

Bare/unwrapped/stray text found in element "body"

or:

Text found outside any tag.

JSWolf · 07-18-2026, 05:47 AM

Quote:

Originally Posted by Kayadelenium

.h4a — a class selector named h4a is a perfectly legal selector; there’s nothing wrong with it to report. If the intent was a different class and this is a typo, that’s a spelling question a validator can’t see — the selector itself is valid CSS.

It's not .h4a. It's just h4a (no period). There is no h4a.

Thank you for diving into the CSS. It's no good when epubcheck says an ePub is good to go and it's not because the CSS has mistakes.

JSWolf · 07-18-2026, 05:50 AM

Quote:

Originally Posted by Doitsu

How about:

Bare/unwrapped/stray text found in element "body"

or:

Text found outside any tag.

How about:

Bare/unwrapped/stray text in element "body" is outside any tag.

KevinH · 07-18-2026, 11:56 AM

Quote:

Originally Posted by Doitsu

@KevinH

Out of curiosity, I tested an epub3 book with some elements that were at one point deprecated in XHTML.

Spoiler:

epubveri flagged: big, center, font and strike.

However, EPUBCheck only flagged big and center.

EPUBCheck output:

Spoiler:

Would you agree that this is an actual EPUBCheck bug?

Yes, it seems like it but whatwg (the living html spec group) only removed support for big, font, and center, whereas strike afaict is still just deprecated.

The funny thing is most modern browsers do not exactly implement the whatwg standard and they purposefully keep old tags around (ie. they deprecate them but do not remove them) to maintain pretty full backwards compatibility.

If the browsers did not do that, that whole whatwg house of cards would come down since a living standard moves too fast to be truly useful for anything over 5 years old.

For example our gumbo implementation of the whatwg spec includes all of them.
And luckily chrome / QtWebEngine has kept support for most of them. Because without that backwards compatibility, Sigil would soon have to drop support for most epub2 epubs and many early epub3 epubs since Preview would fail.

Browser devs luckily seem to understand backwards compatibility is very useful. Without isit most epub ereaders that support epub2 would be toast as the same webengine/webkit is used to display both epub2 and epub3.

Kayadelenium · 07-18-2026, 05:17 PM

v0.5.16 is out — a bug-fix release, straight from this page’s feedback.

Doitsu — the misplaced </p> reported twice. Fixed. You were right that reporting the same stray text twice is wrong. The cause was two checks overlapping: a hand-coded one I wrote back in 0.5.7 (before epubveri had any EPUB 2 content model), and the EPUB 2 RELAX NG grammar I added in 0.5.13, which now catches the same thing. I removed the hand-coded one — the grammar is the single source of truth, and it also covers stray text in any other block-only element, not just <body>. And I took your and JSWolf’s wording point: the message is now “stray text is not allowed directly in “body”; wrap it in an element” instead of the “character data” phrasing. It says what’s wrong and what to do.

Doitsu / KevinH — big, center, font, strike. I dug into this one, because it decides whether epubveri is right or just noisy. The authority here is the WHATWG HTML spec’s non-conforming features list, and it lists strike in the same section as big, center, font and tt — all “obsolete, must not be used”. So, KevinH, with respect: strike isn’t merely deprecated, it’s non-conforming, same shelf as font. (s and u are not in that list — they’re still valid, which is why epubveri leaves them alone.) So epubveri flagging big/center/font/strike/tt is the spec-correct behaviour; it’s not me inventing errors.

Here’s the wrinkle, and why I’d like one more thing from you before I take it upstream. I checked EPUBCheck’s own bundled XHTML schema (the nu.validator HTML5 RELAX NG it ships): it defines s and u, and it does not define strike, font, tt, big or center at all — which means by its own schema EPUBCheck should reject all of them, not just big/center. That contradicts what we’re seeing, so before I file anything against EPUBCheck I don’t want to be wrong about what it actually does. Could you paste EPUBCheck’s real output for that test book? Your earlier one was inside a spoiler I couldn’t fully read. If EPUBCheck genuinely passes font and strike, that’s a solid bug report with the schema to back it; if it flags them after all, then there’s no divergence and we quietly agree. Either way I’d rather have the evidence first — I’ve been wrong guessing before.

JSWolf — h4a (no dot). Understood, thanks for the correction: a bare h4a type selector, for an element that doesn’t exist. It’s valid CSS — a type selector for an unknown element name just matches nothing — so it isn’t a validity error, but I agree it’s a real quality signal, the kind of thing that slips past EPUBCheck. It belongs in the opt-in --advisory layer next to the unknown-property check. Two things make it non-trivial, so I’ve filed it rather than rushed it: styloria (the CSS parser) doesn’t parse selectors yet, and the set of “real” element names is fuzzy once you count SVG, MathML and author custom elements. Tracked as #28.

JSWolf — a font-family with no @font-face. I want to be straight about this one rather than half-ship it: I don’t think it can be done without a lot of false positives, and it’s the same reason EPUBCheck doesn’t. A font-family may name an embedded font (which needs an @font-face) or a system font like Georgia or Arial (which must not have one) — and CSS gives no way to tell the two apart. Flagging every font-family without a matching @font-face would fire on essentially every book that uses a system font. The only way to narrow it is a hand-kept “system font” allowlist, which is device-dependent and never complete. Filed as #29 with that caveat, in case a good heuristic turns up — but I’d rather report nothing than report wrongly.

Binaries: v0.5.16 release page. Thanks, all — this page alone produced a real bug fix and a message that actually reads like English.

Doitsu · 07-18-2026, 06:15 PM

Quote:

Originally Posted by Kayadelenium

Could you paste EPUBCheck’s real output for that test book? Your earlier one was inside a spoiler I couldn’t fully read. If EPUBCheck genuinely passes font and strike, that’s a solid bug report with the schema to back it; if it flags them after all, then there’s no divergence and we quietly agree. Either way I’d rather have the evidence first — I’ve been wrong guessing before.

I attached the complete output (txt + json) and the actual epub3 test book.

The W3C Validator also doesn't like strike and font.

Quote:

Originally Posted by W3C

Error: The big element is obsolete. Use CSS instead.
From line 12, column 30; to line 12, column 34
uses the <big>big</b

Error: The center element is obsolete. Use CSS instead.
From line 14, column 3; to line 14, column 10
1.</p>↩↩ <center><p>Thi

Error: The font element is obsolete. Use CSS instead.
From line 14, column 34; to line 14, column 61
raph uses <font color="red" size="+1">colore

Error: The strike element is obsolete. Use del or s element instead.
From line 14, column 134; to line 14, column 141
(s)</s>, <strike>strike

07-17-2026, 05:43 AM	#91
JSWolf Resident Curmudgeon Posts: 84,218 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	delete post Last edited by JSWolf; 07-17-2026 at 06:02 AM.

07-17-2026, 05:51 AM	#92
JSWolf Resident Curmudgeon Posts: 84,218 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I'm trying 0.5.11. Would you mind removing -i? I don't see a need for it. Thanks. Another fix, when the CSS references named fonts but there is no @font-face for it, please flag it as either an error or a warning. Also, please check the CSS for errors. The CSS has an error of font-eight that should be flagged as an error. There is also a class for h4a which is also an error as there is no h4a. font-size: x-small;; was missed as an error. Last edited by JSWolf; 07-17-2026 at 08:16 AM.

07-17-2026, 08:28 PM	#98
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.14 is out, with Doitsu’s empty-metadata case and a first pass at JSWolf’s CSS ones. Doitsu — empty dc: metadata (EPUB 2). Fixed: an empty (or whitespace-only) Dublin Core element in an EPUB 2 package — an empty dcublisher, dc:creator, and so on — now draws OPF-072 at usage level, which is what EPUBCheck reports. dc:title and dc:date are left to their own existing rules. EPUB 2 only, and usage-level, so it never changes a book’s valid/invalid verdict — it just tells you the element is carrying nothing. JSWolf — font-eight, x-small;;, and .h4a. One is a real find, two aren’t, and I’d rather say which than quietly ship all three. font-eight (a typo for font-weight) is the real one: a property name CSS doesn’t define. The catch is that EPUBCheck doesn’t validate property names at all — it never flags an unknown property — so reporting it by default would be me inventing an error the authority hasn’t decided on, which is the one thing I’ve said I won’t do. So it’s there, but opt-in: run with --advisory and you get ADV-001: 'font-eight' is not a recognized CSS property, at the exact line and column, at usage severity (it never affects the exit code). Same for an unknown at-rule descriptor — a bogus @font-face descriptor is ADV-002. Off by default the output is byte-for-byte what it was. Two things worth spelling out about how it decides “unknown”, because the failure mode of a property linter is false positives: The known-property list is the union of the W3C “all properties” index and MDN’s property data — MDN carries the legacy aliases and SVG properties the W3C index omits (word-wrap, text-rendering, and friends), which were the false positives when I tried the W3C list alone. Vendor-prefixed (-webkit-…) and custom (--…) names are exempt. It’s a distinct message family (ADV-…), deliberately not a CSS-0xx. Matching EPUBCheck on verdicts means not minting a code in its namespace for something it doesn’t define. The other two I checked and don’t think are errors: x-small;; — the doubled semicolon is an empty declaration, and CSS Syntax says to just discard it. It’s valid; EPUBCheck doesn’t flag it, and neither do I. (If you meant something else by it, show me the whole rule and I’ll look again.) .h4a — a class selector named h4a is a perfectly legal selector; there’s nothing wrong with it to report. If the intent was a different class and this is a typo, that’s a spelling question a validator can’t see — the selector itself is valid CSS. The property-name check rides on a separate small library I’ve been building alongside this (styloria, a pure-Rust CSS parser); the validation is the part that’s new in it. Value- level checking — whether color: 3px is nonsense — is a much bigger job and isn’t in yet. And there’s more to come — this is a first pass, not the finished picture. A few improvements are already lined up: the advisory checks only run from the command line for now (the in-browser/WASM build can’t opt in yet), value-level CSS checking is the natural next layer, and the deeper content-model work continues. I’d rather ship these in small, verifiable steps than announce a big list, so I’ll post them as they land — and this thread has been better than any roadmap for deciding what’s worth doing next. Binaries: v0.5.14 release page. Keep them coming — the font-eight case is exactly the kind of thing I’d never have written a test for on my own.

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

07-17-2026, 06:38 PM	#97
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Hi, I released two versions, but I noticed a few more bugs; I'm working on fixing them. Your latest test and the other tests are passing successfully. I also fixed more issues than just those related to `big`, `center`, `font`, and `strike`. I'll let you know and write a detailed post once I've completely cleared out the bugs.

07-18-2026, 04:24 AM	#99
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.15 is out, and it’s the one I’d been putting off: the XHTML content model is now validated properly — the deepest, hardest part of matching EPUBCheck, and the part I said from the start I’d leave for last. Read this first if you validate your own books: this release changes verdicts. A book that nests elements illegally, or points an attribute at an id that isn’t there, now comes back invalid (RSC-005) where 0.5.14 passed it. That’s not a regression — it’s catching real errors EPUBCheck catches too — but if a book that was green suddenly isn’t, this is almost certainly why. Check the new message before assuming something broke. What’s actually new, in three parts: Nesting rules — the constraints a grammar structurally can’t state, because they’re about a node’s ancestors, not its immediate contents. An <a> inside another <a>; interactive content (a <button>, a <select>, an <audio controls>) inside an <a> or <button>; a <form> inside a <form>; <header>/<footer> nested in each other; a <label> in a <label>. Element placement — the <span> and loose text directly under <body> that Doitsu reported way back — was already caught by the grammar; this is the other half. Broken references — every id an attribute points at now has to exist, and where the reference is typed, point at the right kind of element: aria-describedby / aria-labelledby / aria-controls and friends must resolve; <label for> must target something labelable; headers must name <th> cells in the same table; aria-activedescendant must be an actual descendant. This is the one I think matters most day to day — a dangling aria-describedby is a real accessibility bug and easy to introduce by editing. A handful of smaller structural rules — duplicate <map> names, a <select> with two selected options, more than one <meta charset>, and so on. All of it is EPUB 3, all reported as RSC-005 at the offending element with a line and column, and all verdict-matched to EPUBCheck — I check each rule fires on the mistake and stays quiet on the valid shape, and the whole EPUBCheck test corpus is unchanged. Thanks to Doitsu for the original report (thread post #54); this closes it out. One other thing, for the CSS crowd: the opt-in --advisory check from 0.5.14 — the one that flags a misspelled CSS property like font-eight — now works in the in-browser (WASM) build too, not just the command line. Still opt-in, still never changes a book’s verdict. Binaries: v0.5.15 release page. As always, the fastest way to find the next bug is to point this at a book EPUBCheck disagrees with and tell me — that’s been worth more than any test I’d have written on my own.

07-18-2026, 05:17 PM	#104
Kayadelenium Enthusiast Posts: 28 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.16 is out — a bug-fix release, straight from this page’s feedback. Doitsu — the misplaced </p> reported twice. Fixed. You were right that reporting the same stray text twice is wrong. The cause was two checks overlapping: a hand-coded one I wrote back in 0.5.7 (before epubveri had any EPUB 2 content model), and the EPUB 2 RELAX NG grammar I added in 0.5.13, which now catches the same thing. I removed the hand-coded one — the grammar is the single source of truth, and it also covers stray text in any other block-only element, not just <body>. And I took your and JSWolf’s wording point: the message is now “stray text is not allowed directly in “body”; wrap it in an element” instead of the “character data” phrasing. It says what’s wrong and what to do. Doitsu / KevinH — big, center, font, strike. I dug into this one, because it decides whether epubveri is right or just noisy. The authority here is the WHATWG HTML spec’s non-conforming features list, and it lists strike in the same section as big, center, font and tt — all “obsolete, must not be used”. So, KevinH, with respect: strike isn’t merely deprecated, it’s non-conforming, same shelf as font. (s and u are not in that list — they’re still valid, which is why epubveri leaves them alone.) So epubveri flagging big/center/font/strike/tt is the spec-correct behaviour; it’s not me inventing errors. Here’s the wrinkle, and why I’d like one more thing from you before I take it upstream. I checked EPUBCheck’s own bundled XHTML schema (the nu.validator HTML5 RELAX NG it ships): it defines s and u, and it does not define strike, font, tt, big or center at all — which means by its own schema EPUBCheck should reject all of them, not just big/center. That contradicts what we’re seeing, so before I file anything against EPUBCheck I don’t want to be wrong about what it actually does. Could you paste EPUBCheck’s real output for that test book? Your earlier one was inside a spoiler I couldn’t fully read. If EPUBCheck genuinely passes font and strike, that’s a solid bug report with the schema to back it; if it flags them after all, then there’s no divergence and we quietly agree. Either way I’d rather have the evidence first — I’ve been wrong guessing before. JSWolf — h4a (no dot). Understood, thanks for the correction: a bare h4a type selector, for an element that doesn’t exist. It’s valid CSS — a type selector for an unknown element name just matches nothing — so it isn’t a validity error, but I agree it’s a real quality signal, the kind of thing that slips past EPUBCheck. It belongs in the opt-in --advisory layer next to the unknown-property check. Two things make it non-trivial, so I’ve filed it rather than rushed it: styloria (the CSS parser) doesn’t parse selectors yet, and the set of “real” element names is fuzzy once you count SVG, MathML and author custom elements. Tracked as #28. JSWolf — a font-family with no @font-face. I want to be straight about this one rather than half-ship it: I don’t think it can be done without a lot of false positives, and it’s the same reason EPUBCheck doesn’t. A font-family may name an embedded font (which needs an @font-face) or a system font like Georgia or Arial (which must not have one) — and CSS gives no way to tell the two apart. Flagging every font-family without a matching @font-face would fire on essentially every book that uses a system font. The only way to narrow it is a hand-kept “system font” allowlist, which is device-dependent and never complete. Filed as #29 with that caveat, in case a good heuristic turns up — but I’d rather report nothing than report wrongly. Binaries: v0.5.16 release page. Thanks, all — this page alone produced a real bug fix and a message that actually reads like English.