[Hitch]

Originally Posted by KarlB

I've tried various different methods, actually. I've been putting the "id=" anchor into a separate "<a href=>" element from the one that links from the footnote back to the body text, which is different from the code snippets you've provided in this thread. I'll have to try your method at some point.

I'm not sure that I posted a method, did I? (wonders if her brain is going). if I did, it likely works. (Famous last words...)

I've also had trouble with the popup displaying more than a single footnote at a time. I've found that the Kindle code doesn't always just take all text from one "<a>" element to the next (as was reported elsewhere in this thread), and that whether or not the <a> element is empty (as in "<a href=blah blah></a>") doesn't consistently make a difference either (contrary to what has also been reported in this thread).

Not following: you DO or do NOT want the pop-up to include more than one footnote? (Honestly..I don't know what we're doing different, but I just haven't seen these problems.)

In fact, I've found that I can get different behavior in the popup without changing any of my footnote-linking code at all. I've "fixed" footnote popup problems, only to have them reappear when I changed parts of my html that were completely unrelated to footnote links -- changes like inserting a few additional <p></p> paragraphs of plain text into my test-book.

And how did that affect the behavior?

So one warning I'd pass along to anyone reading this thread is not to trust any "fix" you come up with. What works perfectly well in one book may magically decide not to work in another book.

Trust me, anyone who's been making eBooks for more than 5 minutes already knows: what worked 5 minutes ago may not work now. ;-)

I've been using the W3C html validator on my html at all stages of my testing, BTW. I generate my Kindle books by passing an OPF to KindleGen. As one might expect, I find this business a teensy bit frustrating. Because they couldn't be bothered to implement this popup feature in a rational way, Amazon is basically breaking into my house in the dead of night and inserting bugs into my previously correct and fully functional code. Thanks Amazon.

Not to disparage clean code--I never would--but I find that the relationship between code validation and what works or doesn't in ePUB and MOBI is pretty...diffuse in terms of relation, in the adjective sense. Broadly UNrelated.

I mean...I have a book in-house, that we resolved "adequately" for the client's purposes, but not for mine. It simply won't WORK. Now, it's been validated 5 ways from Sunday, but if you put two (specific) fonts in this sucker, both fonts get ripped out at the KDP. (There are 6 fonts, including all faces, in the book). Put in one or the other--works great. Put the main body font (A basic Sans serif face--SS) in by itself, great. Put the hw fonts in...kablammo, the built mobi loses ALL fonts at KDP. Stripped. Put the hw fonts in without the SS, and they work. This happens whether you embed the SS, or call it from the firmware (that's fascinating, isn't it?). There is NOTHING wrong with the coding. Not one thing. The HTML validates, the CSS validates...by every standard known, it's perfect. It simply doesn't work.

And--here it gets interesting--all our usual "solves" don't work, either. Replacing the first SS with another sans serif didn't work. cheating, and using spans around those body paragraphs that are supposed to be SS--nada. Zip, zein, zilch, nothing. (There are two characters; one speaks in sans-serif, one in serif). The span approach didn't work because--it seems--that there might be a "span limit" at KDP, too. (Who knew? Given the advent of INDD for eBooks, I find that mind-boggling, because INDD lives and dies on spans, but...I have definitive proof that adding ONE MORE SPAN to a book caused it to fail.)

Now, we've had books that had fonts stripped before; that's not as unusual as it sounds. I don't mean, don't display; I mean, ripped right out of the book. But never seen anything like this. 2500~ books in...and this one is a first.

It's unrelated to your specific issue, but my point is: not all failures to work are explicable, in terms of KDP. We put in well over 100 hours of real time, trying to troubleshoot this book, not for the client as much as just so we would KNOW. And we still do NOT know the "why." Just that it happens. And not all failures have ANYTHING to do with bad code. Or even remotely lousy code. Or...well, you get the drift. So--validation is good, and I'd never dissuade you from doing it, but that's not proof of anything other than, you don't write lousy code.

Hitch