EPUB-Checker error: undefined property

[Dabcar]

Hi,

I get the following errors from EPUB-Checker:

Undefined property: 'endnotes'

Undefined property: 'endnote'

What does this mean?

I'm using the following HTML (as an example) for EPUB 3 based on suggestions from others:

<aside epub:type="endnotes">
<h2>Notes</h2>
<ul class="endnotes">
<li id="footnote-041" epub:type="endnote" class="fn-txt"><a class="_idFootnoteAnchor" href="page-14.xhtml#footnote-041-backlink">37</a>footnote text here. </li>
<li id="footnote-040" epub:type="endnote" class="fn-txt"><a class="_idFootnoteAnchor" href="page-14.xhtml#footnote-040-backlink">38</a> footnote text here.</li>
</ul>
</aside>

How do I define this so it works?
Thanks.

[JSWolf]

Is this an ePub 3 or ePub 2 eBook?

[Tex2002ans]

Originally Posted by Dabcar

I get the following errors from EPUB-Checker:

What version of epubcheck are you using?

(Or are you using a plugin? Or a specific site?)

Originally Posted by JSWolf

Is this an ePub 3 or ePub 2 eBook?

Says EPUB3 in his post, but could be Dabcar's accidentally using this markup in an EPUB2 book.

Do you use Sigil? If you open the book in Sigil, the titlebar has a little line that says if your book is 3 or 2:



or if you run epubcheck, one of the first lines should tell you whether it's checking in epub2 or epub3 mode.

Originally Posted by Dabcar

What does this mean?

epub:type="endnote" and "endnotes" are both perfectly valid according to the EPUB3 specs:

https://idpf.github.io/epub-vocabs/structure/#notes

along with "footnote" and "footnotes".

... so something else here may be causing the trouble.

Originally Posted by Dabcar

I'm using the following HTML (as an example) for EPUB 3 based on suggestions from others:

(Can I ask where you got this code suggestion from?)

From what you're showing, the code does seem to look "okay".

I probably wouldn't use a giant <ul> though.

Originally Posted by Dabcar

How do I define this so it works?

To be safe, I would wrap each note in an <aside> and use <p>, so something along these lines may work better:

<aside epub:type="endnotes">
<h2>Notes</h2>
	<aside id="fn1" epub:type="endnote">
		<p class="note"><a href="#ftn1">[1]</a> This is text for endnote 1.</p>
	</aside>
</aside>

See Doitsu's EPUB3 footnotes test-case from 2016 (not much has changed since then).

That would more gracefully fallback, and work a bit better across a variety of readers.

[JSWolf]

But before doing any of the code suggestion that Tex2002ans suggested, make sure your eBook is ePub3. Otherwise, none of it will work.

[Dabcar]

Originally Posted by JSWolf

Is this an ePub 3 or ePub 2 eBook?

EPUB 3. EPUB-Checker says: "Validating using EPUB version 3.0.1 rules"

[Dabcar]

Thanks both JSWolf and Tex2002ans.

Tex2002ans, your question about what version of EPUB-Checker made me check out updates. I have now updated it, and EPUB-Checker has changed it's Validation to "EPUB version 3.2 rules, and now there are "no errors or warnings detected. EPUB is valid!"

However, your comment, Tex2002ans, about the need to gracefully fallback and work better across a variety of readers does concern me. I also used the FlightDeck service to check it, and it says Apple doesn't like the endnotes and endnote declarations (even though in tests they work fine in Apple's Books app on my Mac. I changed the endnote/s to footnotes and footnote respectively and it no longer rejects the page in Flightdeck. Go figure.

Concerning using the<ul> list, they are not mammoth (the largest is around 20), as, according to everything I've read here and elsewhere including books, it's best to use HTML properly. These are a list of footnotes at the end of each chapter (endnotes), hence my choice. Another reason for going for the list (or even p or div tags)instead of wrapping each footnote in an aside tag was that I read in these forums that this stops iBooks from using its pop-up feature. I tested this out with Apple's Books app, and it's true. The list tags semantically are correct as well as they work in Books (iBooks). The list works fine in ADE, but haven't tried a Kindle yet.

As for where I got the code suggestion from, what I meant was the epub:type declarations appear to be correct. I haven't seen footnotes used in a list before, but, to me, it is logical. However, if it's a problem, I'll take them out and put them in div or p tags (as others on this forum have suggested).

Thanks for the responses. Any advice is welcome. It's a long time since I put together an ebook and things have moved on quite a bit.

[Tex2002ans]

Originally Posted by Dabcar

Tex2002ans, your question about what version of EPUB-Checker made me check out updates. I have now updated it, and EPUB-Checker has changed it's Validation to "EPUB version 3.2 rules, and now there are "no errors or warnings detected. EPUB is valid!"

So "EPUB-Checker", you actually mean epubcheck:

https://github.com/w3c/epubcheck/releases

the commandline tool?

(PS. And yuck, when the heck did they change the capitalization to "EPUBCheck"?)

And be aware, while EPUB3.2 is supposed to be backwards compatible with EPUB3.0.1, the reality is that the vast majority of the readers out there that aren't following the latest/greatest specs.

Originally Posted by Dabcar

However, your comment, Tex2002ans, about the need to gracefully fallback and work better across a variety of readers does concern me.

Yep, and that's the thing too... sometimes the latest specs sadly do not match the reality of the actual devices out there... so depending on where you're selling, you have to take into account LOTS of different (old) renderers.

Two examples:

InDesign's "Export > EPUB3" likes to focus on creating iBooks-focused code, but there are plenty of non-iBooks EPUB3 readers, (and even within the Apple ecosystem, lots of older/buggier iBooks versions [iPad 1s floating around]).

ADE 4.5 is the latest, and may display your book okay, but many older devices have an embedded RMDSK that's ~ADE 2.0.

Originally Posted by Dabcar

I also used the FlightDeck service to check it, and it says Apple doesn't like the endnotes and endnote declarations (even though in tests they work fine in Apple's Books app on my Mac.

iBooks on Mac =/= iBooks on iOS... but I'm no expert (I refuse to mess with Apple's rotten/locked-in ecosystem).

But to my knowledge, the most well-supported type is epub:type="footnote".

But someone with more Apple-centric knowledge might be able to jump in and correct me.

Originally Posted by Dabcar

Concerning using the<ul> list, they are not mammoth (the largest is around 20), as, according to everything I've read here and elsewhere including books, it's best to use HTML properly.

You have to also remember, HTML =/= EPUB.

While EPUB3 (and 3.2) is trying to merge much closer to the overall HTML5 ecosystem, there are still a lot of backwards compatibility, older devices, non-updated and not perfectly spec-compliant readers out there.

I still think it's best to design an EPUB3 that has EPUB2 (and older reader) fallbacks.

For example, <ul> leads to a lot of potential formatting issues in older versions of ADE/RMSDK, and trying to use complicated CSS to override the defaults may fail miserably.

To read more on the topic, see the 2016 topic "Epub3 Foot- End-notes", especially my Post #39+ where I disuses the disadvantages of <ol> (and similar).

Also, there are other readers (such as Kindle and Calibre) which may rely on heuristics to "detect footnotes". Using funky code may break that functionality.

(I'm unsure of how Kindle deals with epub:type endnote/footnote ... I personally don't use much EPUB3 as input... and quality technical research is hard to come by.)

Originally Posted by Dabcar

Another reason for going for the list (or even p or div tags)instead of wrapping each footnote in an aside tag was that I read in these forums that this stops iBooks from using its pop-up feature.

Hmmm... strange. Mind pointing me to those posts?

And which version of iBooks are you using? (And is it Mac or iOS?)

Originally Posted by Dabcar

I haven't seen footnotes used in a list before, but, to me, it is logical.

It's also good to keep in mind much larger-picture issues. Something that may work and look pretty on (latest version of) iBooks, may not work on all the other readers out there.

Better to design a book that works across a broad spectrum, than one that has to be tweaked/updated/adjusted for each platform.

For more info, see one of my favorite talks from last year's Ebookcraft 2019, "Building Ebooks that Last". One of the key points she explains is it's best to KISS, and to aim towards markup that works and remains readable even without CSS (who knows WHAT device/app end-users are going to be reading on... and many override your CSS).

Originally Posted by Dabcar

Thanks for the responses. Any advice is welcome. It's a long time since I put together an ebook and things have moved on quite a bit.

And welcome to MobileRead, I see this was one of your first posts. Glad to have you on board.

[DiapDealer]

It is my opinion that ol and ul elements are best left to non-ebook usage. They offer little benefit (and plenty of disadvantages) to static content to be rendered by multiple ebook readers/apps. Numbers and bullets are not that difficult to code/style manually when you only have to do it once. It'd be different if one was building dynamic content from database records.

[Dabcar]

Thanks for the input and advice.

Tex2009ans:

So "EPUB-Checker", you actually mean epubcheck:

I am using the app version which has in the toolbar: "pagina EPUB-Checker", and in the body of the window under "Validate EPUB": "(EPUBCheck 4.2.2).

But to my knowledge, the most well-supported type is epub:type="footnote"

I think you are correct. Everywhere I look, including the Apple site, they always use footnote/s, plus, using those terms appears to take away the alert.

To read more on the topic, see the 2016 topic "Epub3 Foot- End-notes", especially my Post #39+ where I disuses the disadvantages of <ol> (and similar).

Your first link failed. I checked out the other.

Where do I go to get all the fallbacks required! I've been trying to follow the line of Jiminy Panoz and the Blitz framework.

Hmmm... strange. Mind pointing me to those posts?

I tried to go back and find where the lists were recommended (and did another search), but I think it must have been on other sites such as Stackoverflow, Github etc. — and they appeared to be experienced). Anyway, so, ol and ul lists don't work? That seems to be the opposite to the presenter at the Ebookcraft 2019 recommended by Tex2009ans above [see around 19.55]. Her point at that stage was don't rely on CSSS, but just basic HTML and her whole point (it seemed to me) was that the person who didn't use a the list tag ended up with bad presentation when the CSS was removed. I have to admit, I am confused about this.

DiapDealer:

It is my opinion that ol and ul elements are best left to non-ebook usage. They offer little benefit (and plenty of disadvantages) to static content to be rendered by multiple ebook readers/apps. Numbers and bullets are not that difficult to code/style manually when you only have to do it once. It'd be different if one was building dynamic content from database records.

Thanks for the advice. As mentioned in the last comment to Tex2009ans above, the presenter at Ebookcraft 2019 seemed to be saying the opposite, but I may have it wrong.

I would very much appreciate being pointed in the right direction for finding a list of all the pitfalls and fallback needs. I know that's not going to come in one place, but if anyone can point me to any resources that would help me get up to speed in a reasonable time without having to crawl through mountains of posts and websites (which has been my experience so far), I'd be grateful!

[Tex2002ans]

Originally Posted by DiapDealer

It is my opinion that ol and ul elements are best left to non-ebook usage. They offer little benefit (and plenty of disadvantages) to static content to be rendered by multiple ebook readers/apps.

Agreed.

Worst cases:

• cut-off content
  
  • Large amounts of text within an <li> may not render on next page.
    

Medium cases:

• Busted numbering
  
  • <ol> lists starting at 1 no matter what
    
  • Not gracefully handling non-sequential numbering (1, 59, 100).
    

Lesser cases:

• Piss-poor support for CSS/HTML Styling.
  
  • Capitals, Lowercase, Greek, [...]
    
  • 1), 1., (1), [1], [1.1], [...]
    
  • Want certain symbols instead of a bullet?
    
• The <ol> number itself becoming cropped (especially when it reaches double-digits).

If you hardcoded in the numbers/styling, it would work across all readers... and it's not very likely the book you're digitizing is going to change.

Originally Posted by DiapDealer

Numbers and bullets are not that difficult to code/style manually when you only have to do it once. It'd be different if one was building dynamic content from database records.

Agreed.

The thing that sucks is hardcoded lists aren't as Accessible (not as easy to navigate), and it won't look as pretty (proper indentation/alignment).

... but in this rare case, I would say maximum compatibility trumps all the list bugs.

Originally Posted by Dabcar

Your first link failed. I checked out the other.

All fixed now (I accidentally added space in the URL).

It was just that same thread, just linked to the very 1st post.

Originally Posted by Dabcar

Where do I go to get all the fallbacks required!

Experience, testing, reading up on MobileRead, etc.

But best advice is to KISS, and don't go overboard with relying on complicated CSS + overrides, etc.

Originally Posted by Dabcar

I've been trying to follow the line of Jiminy Panoz and the Blitz framework.

Ehhh... I strongly recommend against "resets" + enormous CSS files.

lumpynose posted a few threads in 2019 bringing up "Standard Ebooks" + Blitz (and similar), and I wrote quite a few in-depth PMs discussing many of the problems. I'll have to see if I can dig those out.

The biggest issue is these things may work on latest iBooks, etc., but break on many real-life devices and override many user-chosen preferences.

And then you throw the 900 pound gorilla in the room, Amazon with MOBI (KFX/KF8/KF7)... and that overly-complicated CSS is going to explode.

If you're designing an EPUB3-for-iBooks-only, okay, maybe you can get away with using a bit more advanced code...

But if you're designing an EPUB-for-everyone or EPUB-to-convert-to-Kindle, then you have to be much, much more conservative with your code.

Originally Posted by Dabcar

I tried to go back and find where the lists were recommended (and did another search), but I think it must have been on other sites such as Stackoverflow, Github etc. — and they appeared to be experienced).

Be careful on the Ebooks Stack Exchange, there's a ton of awful information on there.

And as I said previously, a lot of those tricks may look fine on the latest versions, but will break when tested across a variety of devices/apps.

Originally Posted by Dabcar

Anyway, so, ol and ul lists don't work? That seems to be the opposite to the presenter at the Ebookcraft 2019 recommended by Tex2009ans above [see around 19.55]. Her point at that stage was don't rely on CSSS, but just basic HTML and her whole point (it seemed to me) was that the person who didn't use a the list tag ended up with bad presentation when the CSS was removed. I have to admit, I am confused about this.

Lists are the one case where I strongly disagree with that presentation.

But keeping in mind "no CSS" as a possibility is always a good idea... so you want to use proper semantic markup. For example:

Do use:

• <i>/<em> instead of <span class="italics">
• <h1> instead of <p class="heading1">
• <blockquote><p></p></blockquote> instead of <p class="blockquote">
• <sup> instead of <span class="superscript">
• [...]

Whatever you do, don't use:

• <pre>
  
  • It's a disaster on ereaders, and in many cases will go flying off the page because of not line-breaking.

Originally Posted by Dabcar

I would very much appreciate being pointed in the right direction for finding a list of all the pitfalls and fallback needs.

KISS.

Use your <p>s, use your <h1-h6>, only use very basic CSS where needed:

Simple HTML:

<h2>Chapter 1</h2>
<p class="first">This is an article about X.</p>
<p>In <i>Example Book</i>, he stated:</p>
<blockquote>
	<p>Really long quotation.</p>
	<p>And continuing.</p>
</blockquote>
[...]

with simple CSS:

Spoiler:

h2 {
	text-align: center;
}
p {
  margin-top: 0;
  margin-bottom: 0;
  text-indent: 2em;
}
p.first {
	text-indent: 0;
}
blockquote {
	margin-top: 1em;
	margin-bottom: 1em;
}
[...]

Leave the rest up to the device/user preferences.

No need to clog up the book with cruft like this:

Spoiler:

p.Block-indent {
	color:#000000;
	font-family:"Minion Pro Medium", sans-serif;
	font-size:1em;
	font-style:normal;
	font-variant:normal;
	font-weight:normal;
	line-height:1.125;
	margin-bottom:5px;
	margin-left:25px;
	margin-right:25px;
	margin-top:5px;
	orphans:2;
	page-break-after:auto;
	page-break-before:auto;
	text-align:justify;
	text-decoration:none;
	text-indent:0;
	text-transform:none;
	widows:2;
}

(Took this CSS out of latest InDesign book I worked on.)

InDesign/Hideous CSS Note: For example, see this 2014 post of mine showing some InDesign spaghetti... compared to minimal HTML.

The ebook may "look okay" on the surface, but:

Whoops, I turn on Night Mode (color is forced black).
Whoops, I make the font sizes bigger (things start breaking).
Whoops, I decide to try to change from the embedded font (some devices won't override).

Originally Posted by Dabcar

I know that's not going to come in one place, but if anyone can point me to any resources that would help me get up to speed in a reasonable time without having to crawl through mountains of posts and websites (which has been my experience so far), I'd be grateful!

In your favorite search engine, you could search:

any topic + Tex2002ans site:mobileread.com

I've probably written about everything under the sun at this point. There's no one location for all this info (although I've been working on compiling things the past year).

Hitch is also a fantastic source (runs one of the largest ebook conversion companies, Booknook):

any topic + Hitch site:mobileread.com

and she discusses a lot of the real-life issues/bugs that crop up.

The unfortunate reality is:

If you're putting a book up for sale, you still have to design ebooks with older/buggier devices in mind.

And for Amazon, you still have to workaround the old MOBI format (KF7).

You can't just ignore the old stuff and hope for the best. You'll get bad reviews, get books returned, your books taken down, etc.

[JSWolf]

Do you need ePub3? Are you actually using any features that are not available in ePub2? If you aren't, you can go with ePub2 and not have to worry about fallback. Personally, I find most ePub3 to not need to be ePub3. They can be ePub2 without any loss of functionality.

[BetterRed]

Originally Posted by Tex2002ans

Hitch is also a fantastic source (runs one of the largest ebook conversion companies, Booknook):

any topic + Hitch site:mobileread.com

Free plug for Ruben

any topic + RbnJrg site:mobileread.com

BR

[DiapDealer]

Originally Posted by JSWolf

Personally, I find most ePub3 to not need to be ePub3. They can be ePub2 without any loss of functionality.

We know you do. And you should really stop saying it every time "EPUB3" is mentioned anywhere. It's tiring and its unhelpful. EPUB3 is here, and it's here to stay, Jon. Give it a rest.

[Dabcar]

Thanks again everyone for the advice. I quickly realised how much bloated code is produced by InDesign, so I have stripped almost everything out and used the approach you have indicated. The only real styling is in some of the headings, which need differentiating. I do have a few simple lists. However, one of the indexes uses three levels, so I'm a bit concerned about that (it took forever to recode from InDesign's bloat, and includes two html pages because it is two large).

As for Blitz, I only looked into it because Laura Brady of EPUB Secrets recommended it.

Looks like I've still got quite a bit to learn!

[Tex2002ans]

Originally Posted by BetterRed

Free plug for Ruben

any topic + RbnJrg site:mobileread.com

lol, yes... all of the cool people are trustworthy.

And over the past few years, RbnJrg been getting quite a bit better at marking when things work in EPUB (which ADE he's tested on) + where they won't work in KF8/MOBI.

Originally Posted by Dabcar

I quickly realised how much bloated code is produced by InDesign, so I have stripped almost everything out and used the approach you have indicated. The only real styling is in some of the headings, which need differentiating.

Originally Posted by Dabcar

Looks like I've still got quite a bit to learn!

KISS, and you'll be fine.

Originally Posted by Dabcar

As for Blitz, I only looked into it because Laura Brady of EPUB Secrets recommended it.

Just keep in mind, it's a lot of InDesign + iBooks-focused stuff... so take a lot of that advice with a big grain of salt.

(And if you thought that InDesign code in that topic above looked bad... woowee, you should look at InDesign's Fixed Layout code! Every, single, word, is wrapped in a span about a mile long and absolutely positioned.)

Originally Posted by Dabcar

However, one of the indexes uses three levels, so I'm a bit concerned about that (it took forever to recode from InDesign's bloat, and includes two html pages because it is two large)

Regular Expressions are your best friend.

And if you're the one in charge of designing the book in InDesign, definitely learn how to use Styles. It'll make your life (plus code cleanup) SO much easier.